WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED INVALID
23108
Cookie test fails with Safari 3.2.1
https://bugs.webkit.org/show_bug.cgi?id=23108
Summary
Cookie test fails with Safari 3.2.1
Henk
Reported
2009-01-04 14:08:45 PST
The site uses the following code to determine if cookies are enabled. document.cookie = "TemporaryTestCookie = yes;"; if (document.cookie.indexOf("TemporaryTestCookie=") == -1) { window.location = "
http://sessie.castmanage.nl
"; } The test fails with Safari 3.2.1 but passes with Safari 3.1.2 end FireFox. The problem is that Safari 3.2.1 always leaves one space before the '=' when there are one or more spaces before the '=' character
Attachments
Add attachment
proposed patch, testcase, etc.
Alexey Proskuryakov
Comment 1
2009-01-05 04:42:44 PST
<
rdar://problem/6472634
>
Alexey Proskuryakov
Comment 2
2009-01-05 04:45:01 PST
Cookies are handled by closed source Apple frameworks below WebKit, so I'm closing this bug as INVALID per our process. The issue will continue to be tracked by Apple internally, thank you for reporting it!
Arjan van Bentem
Comment 3
2009-01-19 04:24:02 PST
> Cookies are handled by closed source Apple frameworks below WebKit
Note that this might be an issue in the JavaScript engine instead? I cannot verify if Radar issue 6472634 somehow indicates that Apple thinks this is a bug (can someone comment on that?). Nevertheless, I think the failing code snippet in this very issue report has a flaw itself as well. First of all: of course, it is to be preferred to have all versions of Mac OS handle whitespace in the same manner, so as for <
rdar://problem/6472634
> it would CERTAINLY be preferred to silently ignore any excessive whitespace just like the older versions of Mac OS did. It's a bit hard to find specifications for this. The HTTP headers have been defined in RFC 2965, but JavaScript's document.cookie does not follow that syntax all the way (like it does not allow setting multiple cookies the way a folded HTTP header could do, nor would it ever have to fall back to the older RFC 2109 behavior).
http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-8747038
refers to RFC 2965, which specifies that cookies names (attributes, being tokens) cannot hold spaces. However, this RFC also explicitly states "The syntax above allows whitespace between the attribute and the = sign". Note that nothing is said about allowing whitespace between the = sign and the attribute's value.
https://developer.mozilla.org/en/DOM/document.cookie
always refers to "key=value" without any whitespace, and states "The cookie value string can use encodeURIComponent() to ensure that the string does not contain any commas, semicolons, or whitespace (which are disallowed in cookie values)". So, for JavaScript: I think that no whitespace is allowed AFTER the = sign, though maybe whitespace is allowed BEFORE the = sign. Having said that, I feel that the line document.cookie = "TemporaryTestCookie = yes;"; should not have a space in "= yes". This very space is in fact ignored by many (if not all) browsers, including Safari, but I still feel it should not have been there. Removing that space would, of course, not solve the issue of this very bug report, which is about some versions of Safari not ignoring (all) whitespace BEFORE the = sign. But, seeing that the website developers should not have used the space after the = sign, I'd say that it would be common sense not to add one before the = sign either. In other words (if a client-side cookie test would be useful), the website developers should have used: document.cookie = "TemporaryTestCookie=yes;"; Again, even though I feel that the website developers should fix this, it would CERTAINLY be preferred to silently ignore any excessive whitespace just like the older versions of Mac OS did.
Alexey Proskuryakov
Comment 4
2009-01-19 04:56:30 PST
Thank you, I have added your comment to the Apple internal tracker. The issue is still being investigated (and yes, I'm fairly sure that it is not a JavaScript problem).
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug