dongfangtianyu commented on PR #6251:
URL: https://github.com/apache/jmeter/pull/6251#issuecomment-2003101896
> the core of the issue is that Apache Http Client
I completely agree;
> How about fixing the issue in HTTP client instead?
Perhaps the issues in the Http Client should be fixed within the Http Client
itself, and the changes are substantial.
> he removal of setCharset does not sound right to me as it would cause
using ASCII via MIME.DEFAULT_CHARSET which is just wrong.
I'm not sure where the mistake lies in doing so, could you provide an
example? Thank you.
---
If I understand correctly, the actual effect of
`MultipartEntityBuilder.setCharset` is only on the HTTP header and does not
affect the processing of the HTTP body.
For `multipart/form-data`, its request content encoding is unrelated to the
request headers and instead resides within the various parts of the HTTP Body.
These UTF-8 texts work fine.
So, according to RFC 7578, perhaps HttpClient shouldn't provide the
`setCharset `method? Or perhaps JMeter shouldn't invoke `setCharset`?
It turns out, before HttpClient handles the Charset issue properly, JMeter
just needs to refrain from calling the setCharset method to avoid adding
charset=utf-8 to the request header (although HttpClient remains at the core of
the issue). This doesn't affect the correctness of the HTTP body content (there
might be other impacts not mentioned, feel free to point them out).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@jmeter.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
