-
Notifications
You must be signed in to change notification settings - Fork 50
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
Inconsistent body validation behavior #146
Comments
Hi @setaman , this kind f error message isn't something that should be returned in any circumstances, so it's a bug indeed. I'm not sure about how this package is handling multipart requests and would require investing some time on it. |
Hi @kobik, It is getting even worse. I just found out that the validation of the My first issue, where ...
// is undefined, no body --> no Content-Type header
const contentType = this._getContentType(requestOptions.headers);
...
// the validator is there, but we cannot reach it because of the undefined 'contentType'
// the validator is in methodSchema.body.multipart/form-data
const validator = methodSchema.body[contentType] || methodSchema.body; I put the validation right after multer in the chain. Multer assigns the image to const validator = methodSchema.body[contentType] || methodSchema.body;
// body has no image field
// methodSchema.body.multipart/form-data has no image to
if (!validator.validate(body)) {
return validator.errors || [];
} I really want this library to work correctly and would like to help. But there are inconsistencies in the validation strategies in general. We see that in the described cases the headers are not checked, which in turn leads to the fact that Body cannot be validated. The question is whether you, the creators and maintainers, want to see the validation of the presence of the headers and the body and the correctness of the headers according to the specification as part of the functionality of this library. |
Hi @setaman, indeed we'd like this package to be as consistent and validate correctly according to the specification. You're more than welcome to submit a PR. |
@kobik I will try to find some time between my work and studies to look at the issues |
Thanks @setaman, much appreciated. |
I find there are some inconsistencies in the validation of request bodies, especially with multipart data. First of all, empty body produces
TypeError: validator.validate is not a function
on validation, where specification requires a multipart body. Secondly theContent-Type
attribute is not checked, I can send multipart body where e.g. a JSON body is expected.I am not sure if this is the desired behavior. But from my point of view the existence of the body should be checked during validation if the specification requires a body in the request. Otherwise the consumer of the API will see a mysterious error message and will not be informed about the specification violation.
My setup is like follows:
Specification
Route
Making a request to this endpoint without a body produces an error:
But I expect to see a validation error here. I assume that this is a bug, because a
application/json
body does not cause this error. Although the validation of a missing (but required in spec) raw body correctly indicates that the required fields are not present, but it would be more correct to report that a body itself is missing in the request.So please let me know if my expectations are legitimate or if I have misunderstood the world.
The text was updated successfully, but these errors were encountered: