-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Does round-tripping cookie names work as expected? #1865
Comments
So thinking this out a bit more, the following are valid cookie key characters:
And should not be encoded, but they are:
This means that if someone writes:
This will result in the browser storing two distinct cookies. Obviously an edge case but an edge case non-the-less. |
Just encountered this today in a situation wherein cookie keys included Somewhat related (though maybe should file a different issue) is the use of Would |
I think the current behavior is expected due to the cookie security fix. If there is a way to fix it that does not result in reintroducing a security issue, I would be open to that, but I'm not sure it is possible. Not encoding characters that do not need to be encoded seems fine with me, though. |
While working through the cookie utils methods adding documentation and examples, I noticed the following:
URL encoding the cookie name on the way to the client but not on the way back from the client means that if a server application tries to set the same cookie based on the incoming name, it will have it's percent escapes encoded again, never reaching a fixed point/symmetry.
Not sure if this is the desired behaviour or not. I know there is a security issue with decoding cookies which are URL encoded. Just wondering if we've made the right trade off here.
Looking at the relevant RFCs:
Maybe rather than general URL encoded cookie key names, we should either:
token
pattern, ortoken
specific encoded form which encodes and decodes onlyCTLs or separators
as defined by the parser.Sorry to get pedantic about this but I'm a little concerned that URL encoding cookie keys is probably not the right behaviour and maybe we should follow the RFCs here more closely.
The text was updated successfully, but these errors were encountered: