-
-
Notifications
You must be signed in to change notification settings - Fork 808
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ULR parser percent encoding corrupting query params #2883
Comments
I've found similar behaviour as well which may or may not be intended. This URL (as a string) This URL
|
What's the status? This is causing big problems for me. I need to have a temporary workaround. Is there a downgrade path? or workaround like marking a url as "raw" if you're sure it does not need further escaping? I'm on 0.25.1 and suffer from this badly when generating Dall-E images with OpenAI, these look like this: Then it goes through httpx, I'm not sure what it makes of it, but it's definitely returning 403. Is it being double encoded because there is a slash in image/png after the query string started? |
Encoding slash is not really a bug. But double encoding stuff already encoded is. It must decode before encoding in that case. |
@ttys0dev what server is this? It should url decode query parameters before checking them. |
I think apache or something, not something I control.
Well...it doesn't....so we need a way to not url encode. |
Well apache will just forward it to the web application. So not the http server that decode. That said i also think we can revert parts of that change |
I think it's some ancient perl based web application. |
According to curl, it's Here is an example of a double encoded URL returned by dall-e: >>> httpx.URL('https://oaidalleapiprodscus.blob.core.windows.net/private/org-LP5NjDb8vYKPpVtDZvsvnJzU/user-UEtOcH2nUvzzuecmNwOfvUg0/img-K2X7yJMMM2jrmbta14WUn3jS.png?st=2023-12-04T21%3A30%3A24Z&se=2023-12-04T23%3A30%3A24Z&sp=r&sv=2021-08-06&sr=b&rscd=inline&rsct=image/png&skoid=6aaadede-4fb3-4698-a8f6-684d7786b067&sktid=a48cca56-e6da-484e-a814-9c849652bcb3&skt=2023-12-04T05%3A46%3A14Z&ske=2023-12-05T05%3A46%3A14Z&sks=b&skv=2021-08-06&sig=Vcgw/ybHxYjADtWWSlFKkwNvXQKeRBCIvk33BAdzCTE%3D')
URL('https://oaidalleapiprodscus.blob.core.windows.net/private/org-LP5NjDb8vYKPpVtDZvsvnJzU/user-UEtOcH2nUvzzuecmNwOfvUg0/img-K2X7yJMMM2jrmbta14WUn3jS.png?st=2023-12-04T21%253A30%253A24Z&se=2023-12-04T23%253A30%253A24Z&sp=r&sv=2021-08-06&sr=b&rscd=inline&rsct=image%2Fpng&skoid=6aaadede-4fb3-4698-a8f6-684d7786b067&sktid=a48cca56-e6da-484e-a814-9c849652bcb3&skt=2023-12-04T05%253A46%253A14Z&ske=2023-12-05T05%253A46%253A14Z&sks=b&skv=2021-08-06&sig=Vcgw%2FybHxYjADtWWSlFKkwNvXQKeRBCIvk33BAdzCTE%253D') The correct URL works:
And the second one doesn't:
|
It appears that the url parser is corrupting query params by incorrectly percent encoding them.
I noticed there's this comment which indicates this percent encoding does not accurately follow the spec.
For example if I have a URL with the following query parameter
type=application/pdf
it gets incorrectly encoded totype=application%2Fpdf
which causes the server to throw an error.This behavior does not match requests which doesn't corrupt the query params.
Possibly related: #2721 #2723 #2856 #2863 #2864
The text was updated successfully, but these errors were encountered: