On Wed, May 10, 2017 at 09:09:59AM +0200, Stéphane Claret wrote: > Hello Willy, > Thank you very much for the detailed answer. > > Some people on the jetty list are arguing that neither chunking or EOF > framing gives a complete guarantee that no failure occurred on the > server side at application level (ie: exception thrown while streaming > the response). > https://github.com/eclipse/jetty.project/issues/805
Thanks for the link, the discussion seems to be hot there :-/ I'm seeing that Greg was involved, and he's also here on the list, maybe he can help. But overall I'm seeing that all the arguments were already provided there, so I hardly see what can additionally be done to convince them to improve their response framing. > Even so, I would not consider it a good reason to ignore the > additional benefits of chunked transfers, better error detection > capability on the network stack just to name one. That's the purpose of chunked-encoding. > Short story, they are (unfortunately) quite happy with the current > behavior despite the remarks. Out of curiosity, I ran some tests on > Tomcat 7 and it had no problem using chunked transfer along with > connection: close, I'll keep that in mind for my next project. In fact I only remember about Jetty acting like this. > Back to haproxy, I understand the reasons why it feels wrong to > compress a stream that might be incomplete and make it appear as a > valid message for the client. But correct me if I am wrong, if the > client was talking to the server directly without haproxy in the > middle, wouldn't it be exactly the same? I mean, he could have its > connection closed due to an error and assume that the response is > complete without any way to tell the difference. My question is, are > you really generating a situation that would not otherwise happen? No because the server would not break its own connection then add the final zero. The problem is in this chain : client --- proxy --- server If the connection breaks between the proxy and the server, and this breakage is the normal signal to indicate the end of the transfer, the proxy will turn this into a zero chunk making the client believe the transfer is complete. A problem between the client and the proxy is easily detected by the client and causes no problem. If the chain looks like this : client --- server The problem can only happen after the chunked encoding so it's not a problem for the client either. Thus the *only* problem is adding chunks on top of a failed transfer. So as you can see the problem is real and is caused by the addition of an intermediary which changes the semantics on an unsafe transmission channel. > Also, in my particular use case, I am running a XML/JSON webservice, > the client side would notice that the message is incomplete while > decoding it so it would not hurt that much. The config lets you decide > which content-type you want to consider for compression so it could be > possible for the operator to decide what's safe and what's not. That's an interesting point, which could possibly fuel the arguments for making a special case of this later. > Anyway, I am going to start testing "http-pretend-keepalive" in > production because I admit it seems to be solving my compression > issues, I may run a comparative load test to see if there is any > serious overhead but I don't expect so. Well if that works for you, please use this as it was designed exactly to address this specific problem. You will not face performance issues or whatever (in fact they may even slightly increase by the removal of a packet). The principle is that haproxy will not emit "connection: close" so Jetty will return chunks, which haproxy can compress, and once the last one is received, haproxy will kill the connection. Hmmm just thinking, is there a reason for not using keep-alive to the servers ? Connection parallelism maybe ? You may want to try http-reuse then, and it will save on connection setup time to the server. Also if you are using XML, then I'm assuming it's totally safe to replay requests so you can even use "http-reuse always" to further improve the performance. It will behave almost like a pool of persistent connections in that any idle connection can be reused by any request. Willy
