MultipartError always has HTTP status of 500

[mxcl]

Since MultipartError does not conform to Abortable (or whatever) it always reports 500, which is incorrect IMO.

It seems to me all should be 400s apart from the nesting one.

This is for decoding submitted multipart data of course.

[siemensikkema]

@mxcl conforming MultipartError to Abortable is not possible in MultipartKit but could be done in Vapor. However, I'd argue that defining how errors are represented in the applications built on Vapor is best decided by the application developers themselves and can be done by writing the conformance in the application. Choosing which status code, and especially which reason goes with which error is a contentious topic!

Closing this issue since it relates to the Vapor package. Feel free to open an issue on Vapor if you don't agree with my reasoning 🙂

AbortError since multipart-kit is now independent of Vapor the conformance of MultipartError to AbortError

[mxcl]

I have to disagree that the default behavior of a web server should be to misreport status codes, but that’s up to you. Certainly as a user the idea that I have to manually go through every single Error type in Vapor and decide how they should be reported is intimidating.

Thanks.

[0xTim]

I agree with @mxcl on this one - it's the equivalent of returning a 500 error when failing on req.content.decode. At best it's ambiguous for clients but also problematic for metrics as well. This does need to be implemented in Vapor however (we do the same with a 404 from Fluent) so I'll transfer this there