Skip to content
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

ServletServerHttpRequest does not use charset parameter of application/x-www-form-urlencoded #34675

Closed
drkslv opened this issue Mar 28, 2025 · 1 comment
Assignees
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement
Milestone

Comments

@drkslv
Copy link

drkslv commented Mar 28, 2025

Hello.
I found illogical behavior of the getBody method of the org.springframework.http.server.ServletServerHttpRequest.
If you send POST requests to the server with a form-url-encoded body, the behavior changes depending on the presence of query parameters in the request url.
If query parameters are not passed, the request body is recoded (decoded/encoded) into utf-8 encoding based on the previously parsed form-url-encoded parameters.
If at least one query parameter is passed, the request body is not recoded.
The behavior is unnoticeable if the original request encoding is utf-8, but is very noticeable if a different encoding is used.

See the example application in the attachment.
bug-spring-web.zip

Test 1.
Send a request with query parameter q and the string "ааа" url-encoded in windows-1251 as %e0%e0%e0 in the body.

> curl --trace - -H 'Content-Type: application/x-www-form-urlencoded;charset=windows-1251' --data-binary 'x=%e0%e0%e0' http://127.0.0.1:8080/path?q=1

In the server logs we will see something like:

: url: http://127.0.0.1:8080/path?q=1
: params: {q=1}
: content-type: [application/x-www-form-urlencoded;charset=windows-1251]
: content-length: [11]
: body: x=%e0%e0%e0

All is correct.

Test 2.
Send a request with the same body but without query parameter.

> curl --trace - -H 'Content-Type: application/x-www-form-urlencoded;charset=windows-1251' --data-binary 'x=%e0%e0%e0' http://127.0.0.1:8080/path

In the server logs we will see something like:

: url: http://127.0.0.1:8080/path
: params: {x=ааа}
: content-type: [application/x-www-form-urlencoded;charset=windows-1251]
: content-length: [11]
: body: x=%D0%B0%D0%B0%D0%B0

Now we see that the request body has been recoded.
The actual content encoding is utf-8 and the actual content length is 20 bytes.
But in the request headers we see old values, which is incorrect.

As a result recoding does not always occur.
And when recoding occurs, the content headers do not reflect reality.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Mar 28, 2025
@rstoyanchev rstoyanchev self-assigned this Apr 1, 2025
@rstoyanchev rstoyanchev added in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Apr 1, 2025
@rstoyanchev rstoyanchev added this to the 6.2.6 milestone Apr 1, 2025
@rstoyanchev
Copy link
Contributor

It looks like ServletServerHttpRequest#getBodyFromServletRequestParameters is fixed to UTF-8. By contrast, FormHttpMessageConverter takes into account the charset parameter.

@rstoyanchev rstoyanchev changed the title ServletServerHttpRequest.getBody illogical behavior ServletServerHttpRequest does use charset parameter of application/x-www-form-urlencoded Apr 1, 2025
rstoyanchev added a commit that referenced this issue Apr 2, 2025
@rstoyanchev rstoyanchev changed the title ServletServerHttpRequest does use charset parameter of application/x-www-form-urlencoded ServletServerHttpRequest does not use charset parameter of application/x-www-form-urlencoded Apr 2, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

3 participants