Open dongfangtianyu opened 1 month ago
I've filed the issue for HttpClient: https://issues.apache.org/jira/browse/HTTPCLIENT-2325
If HTTPClient removes new BasicNameValuePair("charset", charsetCopy.name())
,
or moves it before new BasicNameValuePair("boundary", boundaryCopy)
,
it should be able to solve this problem.
However, I still don't understand the reason behind insisting on calling multipartEntityBuilder.setCharset
in JMeter.
Please enlighten me, and I would be grateful.
I might understand now. Thanks again.
Expected behavior
HTTP Header
Actual behavior
HTTP Header
Steps to reproduce the problem
In JMeter 5.6.3, the request header
Content-Type
formultipart/form-data
is required to include; charset=
.On some web server implementations, including
charset
in the request headerContent-Type
ofmultipart/form-data
can result in parsing errors of theboundary
, leading to a failure in sending form content.Example 1: https://github.com/spring-projects/spring-framework/issues/21599
Example 2: https://bz.apache.org/bugzilla/show_bug.cgi?id=61384
According to the latest RFC specifications, such implementations are incorrect:
In RFC 2046 [4.1.2] :
text/plain
), thecharset
parameter should be passed in theContent-Type
.multipart/form-data
does not belong to thetext
subtype, and the HTTP body may contain both text and binary data.In RFC 7578 [5.1.2], rules for form encoding (
form-charset
) are defined:multipart/form-data
specifies a charset, it should be located in the HTTP body rather than the HTTP header.multipart/form-data
, UTF-8 is used by default.Therefore, HTTP headers like the following are non-compliant with the specification (and cause errors in some web server behaviors):
Interestingly, this HTTP header is also non-compliant with the specification (but doesn't cause errors as it lacks a boundary):
I am not yet familiar with JMeter. If my idea is wrong, please remind me and close this issue.
Thank you.
JMeter Version
5.6.3
Java Version
17
OS Version
No response