On 1 January 2015 at 12:34, Mark Thomas <markt_at_apache.org> wrote:
> On 01/01/2015 10:47, Greg Wilkins wrote:
> Thanks for listing these. Any thoughts on how to express this? I guess
> some options in web.xml.
>
>
How old fashion of you!
I thought we'd do it the way we do everything else in the servlet spec: a
combination of web.xml, xml fragments, annotations and an API with strange
and mysterious rules for combining such mechanisms that will only finally
be clarified in version 5.1 :)
> * Expect 100 handling
>
> Any response > 299 hits an ambiguity in the HTTP/1.1 protocol. Once the
> server sends the response it has no way of knowing if the client has
> received and processed that response before the client sends the next
> packet. Therefore, the server can not tell if the next packet is the
> start of a new request or the request body for the current request. This
> opens up the opportunity for request smuggling. While the spec doesn't
> state this, we currently close the connection for any response with a
> response code > 299.
>
>
Indeed - after extensive research and consultation with the IETF WG, the
resolution that I believe is recommended is that when expect:100 is sent,
there are only two options in http/1.1: expect the body or close the
connection with the response.
ie either 100 continue is sent (and jetty uses the act of calling
getInputStream as the trigger to indicate the servlet is willing to consume
the body (after inspecting headers)) and then the body is expected - OR a
normal response is sent with connection close.
You cannot not send 100 and expect the client to skip the body and read a
new request.
This is not a problem for http/2 which also supports 100 continues, but
does not have the message boundary problems.
> > * Use chunking or EOF for unknown response lengths
>
> If you don't use chunking you can't tell the difference between a
> completed request and one that was terminated part way through. We
> always use chunking to enable clients to differentiate between these two
> cases.
>
> I think it would be helpful to clarify the expected behaviour for the
> above edge cases and I offer up Tomcat's current behaviour as a starting
> point.
>
Agree that is the most reasonable default. Yet we do get a steady stream
of users with poor clients that need chunking turned off. With jetty you
can set Connection:close and that allows chunking to not be used.
I'm a bit marginal on this, as essentially clients should support
chunking. But if we want to help with broken clients having a portable
option to avoid chunking would help.
cheers
--
Greg Wilkins <gregw_at_intalio.com> @ Webtide - *an Intalio subsidiary*
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com advice and support for jetty and cometd.