You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Maybe rather than general URL encoded cookie key names, we should either:
Reject any cookie key that doesn't match the token pattern, or
Have a token 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:
Just encountered this today in a situation wherein cookie keys included # as a separator for additional namespacing.
This was fine when only created & parsed in JS, but but they are overzealously escaped when coming from Rack, breaking compatibility.
Somewhat related (though maybe should file a different issue) is the use of Rack::Utils.escape to encode the value portion. It uses URI.encode_www_form_component under the hood and produces + for whitespace.
Would Rack::Utils.escape_path instead be better? I haven't verified, but I wonder if it would align with JS encodeURI() or encodeURIComponent().
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: