Click one of the red "Bestel" buttons. Safari does not calculate the request URL correctly, and attemps to load "http://www.dixons.nl.aspx/" Same problem with the latest official Safari release (2.0.2/416.13). No problems with FireFox
Confirmed in TOT.
Created attachment 5062 [details] A reduced version of the site I think that this is a server side bug, from what I see. But maybe I'm missing something. I've attached a reduced test case which is only javascript at this point.
Agreed, but it's something in Safari's request that triggers the bug (for example, the Content-Type is different than in Firefox). Further reduction would help.
Someone should examine tcpflow output in Safari vs Firefox to see if it really is the HTTP request going wrong.
Created attachment 5220 [details] tcpflow output tcpflow of Safari and Firefox; parameters for curl to reproduce correct behavior. It is one missing cookie that makes the difference. But why can it be missing?
Looks like Foundation doesn't handle Set-Cookie header the way Firefox does (perhaps, because of a space in the value?): Set-Cookie: Dixons=CookiesEnabled={df2a74e4-5ce2-486b-932a-4d328e5424e6} &expires=2006-01-22 12:18&persist=1; expires=Sun, 22-Jan-2006 11:18:06 GMT; path=/ If I'm right, this bug is the outside open-source WebKit, and should be marked INVALID as such. Please file it at <http://bugreport.apple.com>.
I have researched this and come to the following conclusions: 1. When the dixons.nl server doesn't receive the "Dixons" cookie in that POST request, it redirects to "http://www.dixons.nl.aspx". That's the site's problem, not WebKit's or Safari's. 2. When Safari / WebKit encounters a Set-Cookie header where it doesn't understand the "expires" section, it ignores the cookie. Firefox accepts it and makes it expire at the end of the session, which seems like the more reasonable behavior. PHP example (you must reload once): echo $_COOKIE['ExpiresCookie']; header('Set-Cookie: ExpiresCookie=foo; expires=bar'); 3. When Safari / WebKit encounters a Set-Cookie header where the *value* of the cookie contains the string "expires=" *and* the cookie is actually trying to set its expiration, it gets confused and ignores the cookie: echo $_COOKIE['ExpiresCookie2']; header('Set-Cookie: ExpiresCookie2=expires=; expires=Sun, 22-Jan-2010 11:18:06 GMT'); This is what's happening to dixons.nl because their cookie value contains "expires=". Further observations: 4. The cookie spec in RFCs 2109 and 2965 makes no statement as to how or whether the value portion of a cookie in a Set-Cookie or Set-Cookie2 header should be encoded. 5. This document on cookies which was last modified in August 2005 by the authors of Curl http://curl.haxx.se/rfc/cookie_spec.html states that the value of a cookie in a Set-Cookie header should not contain a comma, semicolon or whitespace, but that if such values need to be used, no particular encoding is recommended nor even required. 6. When a cookie value contains a comma, Safari / WebKit throws away the comma and everything after it. Firefox accepts the entire cookie value: echo $_COOKIE['CommaCookie']; header('Set-Cookie: CommaCookie=Hello, world'); 7. When a cookie value contains a semicolon, Safari / WebKit and Firefox both throw away the semicolon and everything after it: echo $_COOKIE['SemiCookie']; header('Set-Cookie: SemiCookie=Hello; world'); 8. Cookie values containing spaces are no problem for Safari / WebKit or Firefox: echo $_COOKIE['SpaceCookie']; header('Set-Cookie: SpaceCookie=Hello world'); I tested this with the latest nightly WebKit build as of this writing, and Firefox 1.5.0.1, on Mac OS X 10.4.5 on a PowerBook G4. I do not know enough about the separation of Safari and WebKit to say which component has the bug.
A very impressive research! I have filed the results as <rdar://4491105>, and will close this bug as INVALID (not in WebKit).