You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the Issue
It creates a reusable request, but there is a problem if the data is provided in FORM format in the request body.
No parameters are defined for data in FORM format.
Send an HTTP request. - contentType ( application/x-www-form-urlencoded )
Check request parameters.
Expected Behavior
The "cachedBody" will contain the content of the HTTP request body.
However, information about the request parameters cannot be provided.
Because, in the process of creating a newly defined request, we call "Request getInputStream()" of the request.
This invocation alters the value of the "usingInputStream" field.
When calling the method to request information about the parameters, it proceeds to parse the parameters through the parseParameters() method.
The parseParameters() method determines whether to execute the parsing task based on the "usingInputStream" field.
As a result, a situation arises where the values for the parameters are not defined because they have already been read.
Mentioning in the guide that normal operation may not occur in the case of FORM data format could be helpful.
Adding code like " ContentCachingRequestWrapper " provided by Spring would be beneficial, as it allows handling of parameters for FORM data format separately.
The ContentCachingRequestWrapper class provided by Spring also invokes "super.getParameterMap()" to trigger the execution of the "parseParameters()" method.
The " fix CachedBodyHttpServletRequest " image below illustrates a simple approach where, upon receiving data in FORM format, the body is read to directly generate parameters.
Subsequently, when requesting parameters, both the existing request parameters and the generated FORM parameters are provided together.
I'm learning a lot and finding the tutorials provided very useful.
Updating the guide document could be beneficial and helpful to many people.
Screenshots
Custom Request Constructor
Request getInputStream() and usingInputStream
Request parseParameters()
ContentCachingRequestWrapper getParameters
fix CachedBodyHttpServletRequest
Environment (please complete the following information):
OS: [Mac m2]
Develop Env
IntelliJ IDE
Spring boot 3.2.5
Spring Web
The text was updated successfully, but these errors were encountered:
Article and Module Links
Reading HttpServletRequest Multiple Times in Spring
CachedBodyHttpServletRequest
Describe the Issue
It creates a reusable request, but there is a problem if the data is provided in FORM format in the request body.
No parameters are defined for data in FORM format.
To Reproduce
Steps to reproduce the behavior:
Expected Behavior
The "cachedBody" will contain the content of the HTTP request body.
However, information about the request parameters cannot be provided.
Because, in the process of creating a newly defined request, we call "Request getInputStream()" of the request.
This invocation alters the value of the "usingInputStream" field.
When calling the method to request information about the parameters, it proceeds to parse the parameters through the parseParameters() method.
The parseParameters() method determines whether to execute the parsing task based on the "usingInputStream" field.
As a result, a situation arises where the values for the parameters are not defined because they have already been read.
The " fix CachedBodyHttpServletRequest " image below illustrates a simple approach where, upon receiving data in FORM format, the body is read to directly generate parameters.
Subsequently, when requesting parameters, both the existing request parameters and the generated FORM parameters are provided together.
I'm learning a lot and finding the tutorials provided very useful.
Updating the guide document could be beneficial and helpful to many people.
Screenshots
Environment (please complete the following information):
The text was updated successfully, but these errors were encountered: