Reject forms that exceed body parsing limits with 4xx responses - #85
Conversation
parseRequestBodyEx throws RequestParseException or warp's InvalidRequest when a form exceeds a ParseRequestBodyOptions limit. These escaped the handler, so most limits produced a 500, bypassed ErrorFormatters, and could not be distinguished under Lenient. They are now caught and rejected before the handler runs. The response is built by the ErrorFormatters like other body errors, except that size limits always respond with 413 and part header limits with 431.
|
Please take a look @fpringle |
| => Proxy tag | ||
| -> MultipartOptions tag | ||
| -> DelayedIO (Either String (MultipartData tag)) | ||
| -> DelayedIO (Either LimitExceeded (Either String (MultipartData tag))) |
There was a problem hiding this comment.
Maybe we could combine the LimitExceeded and String errors into one error type? e.g.
data CheckError
= ParseError String
| LimitExceeded { statusOverride :: Maybe (Int, String) , limitMessage :: String}There was a problem hiding this comment.
I have added this, but with an additional type to avoid partial record selectors.
| parsed <- check pTag opts | ||
| case parsed of | ||
| Left LimitExceeded {..} -> | ||
| liftRouteResult $ FailFatal $ withStatus statusOverride (formatError request limitMessage) |
There was a problem hiding this comment.
What happens if Lenient is enabled? Should this be treated in the same way as a parse error?
There was a problem hiding this comment.
Ok, with the latest commit, in lenient mode, the handler gets the Either CheckError so that it gets to handle the limit errors just like other parse errors.
There was a problem hiding this comment.
Sorry for another suggestion, but could we now add a new constructor to CheckError for utf8 errors, and only convert it to a String when we're FailFatal-ing?
There was a problem hiding this comment.
There was a problem hiding this comment.
Thank you, I have pushed a commit with this patch.
Co-authored-by: Frederick Pringle <frederick.pringle@fpringle.com>
2 participants
parseRequestBodyEx throws RequestParseException or warp's InvalidRequest
when a form exceeds a ParseRequestBodyOptions limit. These escaped the
handler, so most limits produced a 500, bypassed ErrorFormatters, and
could not be distinguished under Lenient.
They are now caught and rejected before the handler runs.
The response is built by the ErrorFormatters like other body errors,
except that size limits always respond with 413 and part header limits
with 431.