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

[Thomas Becker <twbecker@xxxxxxxxx>]

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