search

jakartaee / servlet

Jakarta Servlet
https://eclipse.org/ee4j/servlet
Other
263 stars 85 forks source link

Clarify support of "Expect: 100-continue" in filters/servlets #307

Open michael-o opened 4 years ago

michael-o commented 4 years ago

I have recently raised a thread on the Tomcat Users Mailing list why servlet filters are not subject to expect continue handling. In detail, when a client sends this header filters and servlets only kicked in after the container has processes the expect continue chain. Making it impossible to send redirects or other status codes prematurely w/o reading the body. In contrast to that Tomcat internal valvles fully handle it automatically.

Please clarify whether a servlet container shall support the handling of expect continue in filters/servlets and how.

stuartwdouglas commented 4 years ago

Undertow can handle this by waiting for the first read from the InputStream to send the 100-continue, if a 417 is sent instead then the connection is terminated after the response is sent.

michael-o commented 4 years ago

@stuartwdouglas Does this mean that filters are subject to expect continue handling? Which of the handling would I see when compared to the link I have provided? Valve or filter?

gregw commented 4 years ago

Jetty's handling of 100-Continues is to wait until either an InputStream or a Reader is obtained from the request to indicate that the filter/servlet/async is willing to read a body. We don't wait for the first read as in undertow, as there may not be a read if we are async.

So in Jetty, a filter is "subject to expect continue handling" in that it can respond without reading the content and then that content will never be sent by the client.

michael-o commented 4 years ago

@gregw, this means that I can in Jetty reject Content-Length before the client is sending the body?

All of this looks inconsistent throughout containers.

gregw commented 4 years ago

@gregw, this means that I can in Jetty reject Content-Length before the client is sending the body?

Yes - and I think in Undertow also.

All of this looks inconsistent throughout containers.

Indeed!

A big problem with the servlet API is that it is trying to both be an application container, which should not care about details (or efficiency) of transfer, but also a protocol handler which does care and wishes to be involved in the details of transfer. If we had a do over, we really should separate these two aspects of the API.