Ensure max-request-size of a Multipart servlet can override a listener max-post-size #1797
Conversation
…erride a listener max-post-size
baranowb
added
bug fix
| // no content - immediately start the next request, returning an empty stream for this one | ||
| Connectors.terminateRequest(exchange); | ||
| } else { | ||
| if (exchange.getMaxEntitySize() > 0 && exchange.getMaxEntitySize() < contentLength && exchange.isResponseChannelAvailable()) { |
There was a problem hiding this comment.
can user set it in code without use of servlets? pure handlers? if so, ignoring it here does not seem good idea.
There was a problem hiding this comment.
If so, than it might not be optimal to remove it, we would need way to handle it both here and in servlet?
There was a problem hiding this comment.
This check and potential rejection was only more recently added with UNDERTOW-2556 but it's too soon to reject here without considering a possible servlet config at all. So removing this a light revert to what it historically had been. I don't think we lose anything significant by moving the check and fail to the ServletIntialHandler instead of the HttpTransferEncoding here since in the ServletIntialHandler, we'll be able to check and fail the request based on all option sources (the listener config, any handler's applied option, or the servlet config) and still fail earlier than waiting on an apps read as we had done before UNDERTOW-2556
There was a problem hiding this comment.
Maybe, my point is that removing it from here denies this part usability for pure handler server. We need a way to leverage this in both types IMHO. If this particular version obstructs upstream, we might need a way to bypass it in case servlet is up in chain?
@fl4via ^^
https://issues.redhat.com/browse/UNDERTOW-2611