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

[michael-o]

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]

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]

@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]

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]

@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]

@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.