-
Notifications
You must be signed in to change notification settings - Fork 105
Description
As the title explains, xh doesn't store any path for session cookies when Set-Cookie
headers don't explicitly set a path
attribute. This means that cookies stored by xh may erroneously be sent to wrong endpoints.
Original issue below, which was bogus
I was playing around with an endpoint that:
- sets a cookie, then
- redirects to someplace else
Example
λ xh \
--session ./xh-session \
-F \
--all \
--print hbHB \
POST http://localhost:8080/jwt/with-redirect \
key=value
POST /jwt/with-redirect HTTP/1.1
Accept: application/json, */*;q=0.5
Accept-Encoding: gzip, deflate, br, zstd
Connection: keep-alive
Content-Length: 164
Content-Type: application/json
Host: localhost:8080
User-Agent: xh/0.23.1
{
"key": "value"
}
HTTP/1.1 303 See Other
Content-Length: 0
Location: http://localhost:9080/other-url
Set-Cookie: Bearer=JWT-here;Version=1
GET /other-url HTTP/1.1
Accept: application/json, */*;q=0.5
Accept-Encoding: gzip, deflate, br, zstd
Connection: keep-alive
Host: localhost:9080
User-Agent: xh/0.23.1
HTTP/1.1 200 OK
Content-Language: en-NL
Content-Length: 3
Content-Type: application/json
Date: Sat, 18 Jan 2025 17:45:14 GMT
{}
NB: actual contents redacted, so Content-Length
isn't correct for the redacted values.
Expected outcome
I would've expected the cookie I got from the initial request to be sent to the second one. Rerunning the command above does in fact send the cookie in the request (since it's been saved from the first request).
Actual outcome
Cookie from earlier request isn't sent to the second one.
Additional info
This may not be a bug, it all depends on what one expects from xh
. But I was a little surprised, so here's the issue anyway 🙂
λ xh --version at 18:50:22
xh 0.23.1
-native-tls +rustls