|Re: [jetty-users] Question about http2 compatibility
Thank you very much Simone, that is very helpfull.We do not explicitly use chunked encoding but simply write the bytes without setting a content size. I did not know http/2 does not use chunked encoding. Perhaps we should handle this differently now we are using http/2?
Unfortunately we can not reproduce this ourselves but I will arrange a test with one of the clients who reported the issue.
Cheers, Silvio On 02/03/2017 09:34 AM, Simone Bordet wrote:
Silvio, On Fri, Feb 3, 2017 at 9:14 AM, Silvio Bierman <sbierman@xxxxxxxxxxxxxxxxxx> wrote:Hello all, We are running Jetty 9.4.1 and recently configured a couple of servers to use http2 (which we only used in development until then). Almost immediately after that we got reports from users who where unable to download dynamically generated SPSS and Excel files above a certain size. Small files would work fine but anything from about 0.5MB and up would fail. In the logs we would see Jetty messages of EofExceptions, broken pipes, ClosedChannelExceptions. We where able to do the same downloads form them without any problems. The customers where mostly using Chrome and IE on Wiindows while we run Chromium on Linux. After disabling http2 the problems went away. But we would prefer to enable it naturally. The downloads use chunked transfer encoding. We do not offload HTTPS and use Jetty SNI support. Does anyone have similar experiences or any idea about how to tackle this?I just tried with our own https://webtide.com website, which also does TLS in Jetty, and have no problems downloading large files, for both Firefox and Chrome on Linux. We did not hear any other similar report. Just a note that HTTP/2 does not use chunked transfer coding (which is a HTTP/1.1 only feature). Would be great if you can reproduce and report the server DEBUG logs. You can also look at what happens on the client; in Chrome, open: chrome://net-internals/#http2 There you will see a list of connections that use HTTP/2. Identify that of your server, and you will see the events for that connection. Report that event list, which should contain the frames that the client sent and those received by the server. We should be able to see something abnormal there.
Back to the top