Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
net/http/cookiejar: escaped path matching #26247
Some servers and software return cookies with paths encoded
Go's default cookiejar can't match those when we make calls back no matter how we make them
There are some characters in RFC6265 which should be encoded/escaped, but space isn't one of the ones listed. This might be a side effect of go being really nice with urls and making it so we rarely have to deal with escaped paths in code.
What version of Go are you using (
If encoding spaces isn't part of the spec, please specify which "servers and software" you are referring to. (The more popular the server/software, the more priority we should give to supporting.)
I don't see anything wrong with your implementation. Probably worth sending a patch with the changes above (plus adding to
In this particular instance it's keycloak but I've had issues with a couple of other things before (including sadly the door security system in the office)
As usual, I'd be normally be on the side arguing to follow the letter RFC but it seems with Go's http client I can't construct a request with any amount of escaping that cookie jar would consider valid against the given cookie.
Sure, gladly. I was content just using a fork called "coooookie" for our own code but I'm finding anything we use from third parties now needs forking to use with our keycloak (as a client)
ooooh, jar_test.go's simple cookie test uses
pushed a commit
Jul 9, 2018
referenced a pull request that will
Jul 9, 2018
added a commit
Jul 9, 2018
referenced this issue
Oct 5, 2018
My reading of RFC 6265 is that encoding spaces in the cookie path is wrong.
RFC 6265 operates on the request-uri as defined in RFC 2616.
This is what net/url.URL.Path represents and this value is used
The whole idea of a cookie path is to prevent the cookie to be sent
Especially as this happens totally opaque between the http.Client and
I think the right solution for your use case would be to manage this
The main question before changing cookiejar.Jar's behaviour would be to
If majority of actual browsers think it is safe to do this unescaping