AspNetCore.Proxy: Character encoding problem in Content-Disposition section in HTTP POST body (multipart/form-data requests)
Hi,
I have encountered interesting problem with proxying http post requests - when uploading files.
Content-Type: multipart/form-data is used and form values are each in it’s own Content-Disposition section (the format is described here: https://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.2).
In Content-Disposition header, characters in the filename value are malformed - different than in the original request.
Example from testing:
from the original request:
Content-Disposition: form-data; name="files"; filename="Abby Wynne - Jak se mít dobře.pdf"
Content-Type: application/pdf
from the proxied request:
Content-Disposition: form-data; name="files"; filename="Abby Wynne - Jak se m�t dobre.pdf"
Content-Type: application/pdf
There is problem when using non-ascii characters in file name. Something with character encoding…
Before, I used ProxyKit (https://github.com/proxykit/ProxyKit). It’s similar library - there was not this problem. It is not supported so I switched to AspNetCore.Proxy. It works without problems in my project (all traffic from one “light” application goes to other one, instead of some local endpoints).
Could you please throw an eye on this issue? 😃
Thanks
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 18 (11 by maintainers)
Finally figured it out.
HttpClientuses an old school RFC forContent-Disposition, so I forced the header.Here is simple ASPNET Core application which makes multipart/form-data http post request with file content to postman-echo.com/post to examine the request. https://github.com/saliksaly/proxy_http_post_multipard_bad_encoding_test
There are three html forms, each sends file in different way:
Try to uload file with non-ascii characters in name (Test こんにちは file.txt for example), you will see broken characters in the filename sent through AspNetCore.Proxy:
Side-note
Direct request from browser differs from request made in automaic tests (using MultipartFormDataContent class). The filename is encoded with base64:
Yes, it seems there is no problem in this test case. I tested the post request and filename is in correct format:
When the request is built so using MultipartFormDataContent object, the request is ok.
But, there is still a problem, when forwarding file request. I will create some repo to show the problem. I am unable to show it in the tests…
Here is pull request for the failing test: #96
Yeah, cool. This is likely an easy fix. Will be even easier if you could add a failing test, and I will debug it.