CookieCutter should not UrlEncode cookie values

I’m working with a backend that is particular about cookie formatting. It’s delivering me a cookie like the following:

Set-Cookie: cookieName=val1=abc&val2=def;

When I make future requests, an identical Cookie header is expected back. Instead Flurl delivers:

Cookie: cookieName=val1%3Dabc%26val2%3Ddef;

The backend does not accept this as it’s not expecting the cookie to be modified. Browsers do not UrlEncode in this way. They only encode semicolon, comma, and whitespace.

The offending code is here: https://github.com/tmenier/Flurl/blob/422b0486ef9cdedee483c14419f2059929fc78cd/src/Flurl.Http/CookieCutter.cs#L75

Can we adjust this to a simple replace for the reserved characters?

[tmenier]

@tranb3r

Most of the time, cookies are set by the server and sent back by the client without any change, so there is no need to decode/re-encode their value. If a user needs to read or set a cookie, maybe we should consider it’s the user’s responsibility to decode/encode the value, according to the escaping scheme used between server and client.

I thought about it some more and I’m in complete agreement. I don’t think it even needs any sort of opt-in parameter; there’s no standard that says to URL-encode cookie values, so the current behavior is just wrong. The spec says servers “should” encode cookie values and even suggests base64, but in any case I don’t think the client library should form an opinion about it.

[tranb3r]

I also need a fix for this issue.

There is a good explanation here of which characters should be banned : https://stackoverflow.com/questions/1969232/what-are-allowed-characters-in-cookies

However, it’s probably not a good idea to force a behavior, since the escaping scheme seems to be a convention between server and client. Most of the time, cookies are set by the server and sent back by the client without any change, so there is no need to decode/re-encode their value. If a user needs to read or set a cookie, maybe we should consider it’s the user’s responsibility to decode/encode the value, according to the escaping scheme used between server and client.

So, a simple fix could consist in adding an option to skip decoding/encoding of cookie values. No breaking change in 3.x, but this option could be inverted in a future major release. A more complete solution could be to let the user configure the escaping scheme per server.