Re: [jetty-users] Changes in Jetty socket close behavior from 9.2 -> 9.4

[Greg Wilkins <gregw@xxxxxxxxxxx>]

Thomas,

sorry to make you the meat in the sandwich here.   Can you relay the following message and if that does not solve the issue, we will engage directly with the varnish mailing list.

As Simone says, HTTP >= 1.1 is a duplex protocol. So much so that there are even intermediate responses that can be sent prior to completion of request handling:  see https://tools.ietf.org/html/rfc7231#section-6.2 and https://tools.ietf.org/html/rfc2518#section-10.1

100 Continue responses are explicitly sent prior to the request body being sent (let alone read).

This is not an optimisation in Jetty.  The order of sending a response vs reading content is for the most part totally beyond our control. Consider the very simple application Servlet that does something like:

doGet(Request request, Response response)

{

   response.setStatus(200);

   response.setContentLength(12);

   response.getWriter().println("Hello World");

   response.flushBuffers();

   

   InputStream in = request.getInputStream();

   while (in.read()>0) {} ;

} 

So here the application explicitly generates and flushes a response prior to even looking at the content.  Jetty cannot hold up sending/flushing the response until the content is read as we would have an unlimited buffering commitment and thus be vulnerable to DOS.

Also once a response is sent, we can't then be obligated to read content that the application itself did not read as we would again become vulnerable to DOS attacks.

I hope this clearly shows that the behaviour is permitted within HTTP and that it is beyond the control of Jetty to prevent it.

regards

  

On Fri, 28 Sep 2018 at 08:18, Thomas Becker <twbecker@xxxxxxxxx> wrote:

I think the rub is that if a client has received but not yet read the response prior to the reset, the socket buffer is cleared and at that point it’s gone. Regardless, I have no stake on who is right or wrong here, it just seems like a pretty significant difference that was not easy to track down and will probably bite other folks too.

-Tommy


> On Sep 27, 2018, at 5:38 PM, Simone Bordet <sbordet@xxxxxxxxxxx> wrote:
>
> Hi,
>
> On Thu, Sep 27, 2018 at 8:11 PM Tommy Becker <twbecker@xxxxxxxxx> wrote:
>>
>> Thanks again, you guys have been super helpful. I found where this happens in the Jetty code (I think), org.eclipse.jetty.server.HttpConnection#onCompleted.  Unfortunately, it appears Varnish cannot currently deal with this, and at least one guy on the list thinks this behavior violates the spec, see https://varnish-cache.org/lists/pipermail/varnish-misc/2018-September/026501.html.
>
> I disagree with the Varnish person.
>
> HTTP/1.1 is a full duplex protocol.
> The fact that the request has not been fully sent is not a reason to
> not read the response, or to discard it.
>
> Imagine a client that sends some data then stops. Varnish forwards the
> data to Jetty. Jetty times out after a while because not all data is
> arrived. Jetty produces a 408 response indicating the timeout.
> Why should Varnish discard the 408 only because "it failed to send the
> full request and won't bother reading the response" ?
>
> --
> Simone Bordet
> ----
> http://cometd.org
> http://webtide.com
> Developer advice, training, services and support
> from the Jetty & CometD experts.
> _______________________________________________
> jetty-users mailing list
> jetty-users@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/jetty-users

_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users

--

Greg Wilkins <gregw@xxxxxxxxxxx> CTO http://webtide.com