Request Body/Content in CustomRequestValidator is null after 2.11.1
On a CustomRequestValidator in Spring MVC application, the new methods request.getRequestBody().toJsonNode() OR request.getRequestBody().toJsonNode().toString(XXX) is not providing the request body. And also the request.getRequestBody().hasBody() method in returns false.
On debugging the PushbackInputStream (in InputStreamBody) is getting closed during the call toJsonNode in the call chain from SchemaValidator. The input stream is closed and not available to use in the customer request validators.
Neither the deprecated method request.getBody() is not giving the contents of the request.
Comments (19)
-
-
The debug screenshot was taken with latest version 2.24.0. The issue still exists.
The input stream getting closed after it’s read in Schema Validator.
There seems to be a comment on introducing input stream issue
on 2020-07-31.#273Ignoring the test case failure’s might need to be reconsidered, Since the request body needs to be fully available for all the custom request validators as well.
-
Ok.
As it is generally working that has something to do with your workflow.
Can you elaborate what you are validating?
Do you use additional filters, interceptors or request wrappers? -
Request body is generally available till 2.11.1, before input stream got introduced. Not from 2.11.2.
In the CustomRequestValidator for things we are not able to define in specs for required, enum or format. We define them in custom format and validate them in Custom Request Validators.
Which one of bellow you think is better?
providing deprecated request.getBody() to provide the string request body as fallback?
Or
Body class could use CloseSheldInputStram( from Apache common IO) wrapping PushBackInputStream instead of direct PushBackInputStream. And close after all the CustomRequestValidators in method RequestValidator.validateRequest().
what are your thoughts?
-
Now I get a glimpse of what you are doing.
First there is the normal request validation using the request body.
Then you have additional custom validation that is also utilizing the request body.That worked before v2.11.1 because back then the body was a string. And the body string can be reused for additional custom validation.
It does not work in newer versions because the request body is now read from an InputStream. The InputStream can not be reused for additional custom validation because it has been closed during first validation.Did I understand that correctly?
-
Yup. 100%
-
I’m sorry for the late response. I got no mail about your comment.
Are you using the default
OpenApiValidationFilter
,OpenApiValidationInterceptor
andOpenApiValidationService
? I ask to know, how and when you call yourCustomRequestValidator
.Your
CustomRequestValidator
is something completely custom? Or is it some part of the swagger-request-validator? -
No worries. Notifications never worked for me
We didn’t extend the Filter, Interceptor or Service.
Custom request validator is added using OpenApiInteractionValidator.Builder.withCustomRequestValidation(). And the same is used in OpenapiValidationInterceptor().
We just call ValidationReport.Message.create() for each failures in the CustomRequestValidator and in the end stream and merge ValidationReport List.
-
I think I’ll introduce a new
ResettableInputStreamBody
thoseInputStream
can be resetted. In case of the Spring MVC Validator the usedInputStream
is resettable.
I don't like to use theStringBody
as validation would be tremendously slower - ~ factor 2.5.
So you have to callbody.reset()
every time before you validate the body in your custom request validation. -
That would be great. appreciate it.
-
I just created pull request #302.
Perhaps you have the chance of building and testing this version and see if your error is fixed. -
Thank you🙂…will check on this today
-
I just merged the latest master into the PR.
You said you have a customized validator. Perhaps you can benefit from the latest changes of issue
#376, too. -
Yes, this does fix the issue. Thanks for the quick turn around and solution. Appreciate it.
-
Can you please include the PR #302 in the next release.
-
@Sven Döring It’s been a while.
As always appreciate your help in fixing the issue. is it included in the base? May I know version to use.
-
It’s still not merged. I just saw merge conflicts in the PR. I’ll have to deal with them first.
May I ask if you’ve upgraded to Spring Boot 3 lately?
-
@Sven Döring oh Okies. Can you please try including in the next release.
Noep, We haven’t started with Spring boot 3 yet. In the process of moving to Java 17. We will most likely start spring boot 3 in a month or so.
-
- changed status to resolved
Available in 2.34.0
- Log in to comment
Does this error still occur with version 2.21.1 or later? There was a fix regarding the PushbackInputStream with
#367.