Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Upgrading to Jetty 9.1

Hi,

I tracked this issue with https://bugs.eclipse.org/bugs/show_bug.cgi?id=426870.

On Tue, Jan 28, 2014 at 12:30 PM, Stefan Magnus Landrø
<stefan.landro@xxxxxxxxx> wrote:
> Hi there,
>
> I've been looking further into the issue, and it seems clear what is going
> on.
>
> This is what happens when running requests through our big ip (not using one
> connect):
>
> jetty 9.1:
>
> whenever a request contains a connection:keep-alive header (the default for
> all browsers I believe, but not for curl), curl hangs until the keep alive
> timeout is reached. Also, jetty replies with a connection: keep-alive header
> in the response.

This is a bug in 9.1.1, that I reported above.
For a HTTP 1.0 request with Connection: keep-alive and unknown
response content length, Jetty should have closed the connection.

> whenever a request does not contain a connection:keep-alive header, curl
> does not hang, and jetty doesn't add a connection:keep-alive to the response
>
> jetty 8:
>
> it doesn't matter if the request contains a connection:keep-alive header or
> not, curl does not hang under any circumstance and jetty will never add a
> connection:keep-alive header in the response.

This is a bug (not tracked, not fixed) in Jetty 8.
The Connection: keep-alive header should be added in the response if
the server knows the response content length.

> In addition, it turns out that big ip, removes the transfer-encoding:chunked
> header that jetty generated (see local debug block) from the response (we're
> using the recommended selective response chunking mode in the big ip http
> profile). In my opinion that is wrong, since it doesn't add the
> Content-Length header, something which would require the connection to be
> closed in order for the client to know when there is no more content.

This would require more investigation.
Curl to F5 is HTTP 1.0, so F5 cannot send chunked content to a HTTP
1.0 client because it won't be able to parse it (chunked content is
only a HTTP 1.1 feature).
If F5 speaks HTTP 1.1 with Jetty, then Jetty is right in replying with
chunked content, and F5 has to perform a transformation by removing
the Transfer-Encoding header, removing the chunked encoding and then
by closing the connection to the client.
If F5 speaks HTTP 1.0 with Jetty, then Jetty is mistaken because it
cannot send chunked content to a HTTP 1.0 client.
In my tests, Jetty never sent chunked content to a HTTP 1.0 client,
but you may be hitting a corner case that I did not.

I just pushed a fix for #426870, can you try it out ?

-- 
Simone Bordet
----
http://cometd.org
http://webtide.com
http://intalio.com
Developer advice, training, services and support
from the Jetty & CometD experts.
Intalio, the modern way to build business applications.


Back to the top