Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC 6265bis: Specify that empty name and empty value cookies should be ignored in 5.4 #1234

Closed
DCtheTall opened this issue Jul 23, 2020 · 2 comments · Fixed by #1236
Closed
Labels

Comments

@DCtheTall
Copy link
Contributor

Currently according to the spec, any cookies set with a Set-Cookie header should be ignored if their name and value are empty. However, this check is not applied in section 5.4 of the spec, and as a result the CookieStore had a bug allowed for sites to work around this check.

To me, this is a symptom of a bigger issue: 6265bis treats non-HTTP cookies as an afterthought, e.g. not specifying how non-HTTP cookies should be accessed other than to ignore HttpOnly cookies.

I think it's worth opening a separate issue just to track whether we add the empty-name-empty-value check to 5.4 of 6265bis, and if there are other checks on the Set-Cookie header in 5.3 that are implied in 5.4 but not made explicit.

@DCtheTall
Copy link
Contributor Author

CC @mikewest

@mikewest
Copy link
Member

As you've noticed, the document currently assumes that 5.4 is only going to be exercised after 5.3. I think this particular issue is distinct from the issue you raise in the other bug, as the only non-HTTP APIs that existed before the async API you're working through used cookie strings, which were parsed just as the header was.

Given that new mechanism, it does make sense to move "If both the name string and the value string are empty, ignore the set-cookie-string entirely." from 5.3 to 5.4. Skimming through, I think that's the only restriction that causes cookies to be ignored at the parsing stage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

Successfully merging a pull request may close this issue.

2 participants