Conversation
|
So, is this in response to PR #5221 ? Also, forgive me for asking, are you human? |
|
Excellent! I'm so glad to hear it, and of course I'm a bit sorry now to have asked. I think we've got the #5221 reference linked now. Now that I'm looking at this, it seems almost certain to me that this change should apply to the pure-port version too; is that in a function right near there? Or maybe the pure-port version actually calls this one? |
|
It might suffice just to run the test with pure-port? |
|
Also, have you taken a look to see what tests there are for the get-pure/impure-port functions? |
|
Thanks, that makes sense, I'll check whether the get-pure-port goes through the same path. I'll also look for existing tests around the get-pure/impure-port functions and update or add one accordingly. |
|
I checked get-pure-port, and it does go through the same underlying HTTP path via http://getpost-impure-port. I also added a get-pure-port test alongside the existing get-impure-port coverage in url-port.rkt, and confirmed the added case passes locally. |
2 participants
Checklist
Description of change
This PR fixes an issue where the fragment portion of a URL (the part after
#) is incorrectly included in HTTP requests made byget-impure-port.According to RFC 3986, fragment identifiers are client-side only and must not be sent to the server. However, the current implementation includes the fragment in the request path.
This change removes the fragment when constructing the request URL, ensuring correct HTTP behavior.
Testing
I reproduced the issue locally using a TCP listener (
nc -l -p 9303) and observed the fragment was included in the GET request:GET /index.html#zzzz HTTP/1.1
After the fix, the request correctly becomes:
GET /index.html HTTP/1.1
The URL structure itself is unchanged; the fragment is only omitted when sending the HTTP request.