On Thu, 14 Nov 2013 00:22:55 +0100 Yann Ylavic <ylavic....@gmail.com> wrote:
> On Thu, Nov 14, 2013 at 12:05 AM, William A. Rowe Jr. > <wr...@rowe-clan.net>wrote: > > > On Wed, 13 Nov 2013 17:14:15 -0500 > > Jim Jagielski <j...@jagunet.com> wrote: > > > > > > > > On Nov 13, 2013, at 2:25 AM, William A. Rowe Jr. > > > <wr...@rowe-clan.net> wrote: > > > > > > > > Here we've unset C-L and T-E. but it makes no sense to wait if > > > > the origin server has no immediate plan to close the connection. > > > > > > I cannot grok the above. The RFC itself does not make > > > the differentiation between keepalive connections or not. > > > So what exactly is the issue? Are you saying we should > > > handle keepalive connections in this path differently? > > > How is that supported by the spec? > > > > Keep-alive (implicit in HTTP/1.1 absent a Connection: close header) > > is orthogonal to an unknown message body. Think about it :) > > Regarding the connection persistance, > http://tools.ietf.org/id/draft-ietf-httpbis-p1-messaging-24.html#rfc.section.6.3states > : > > In order to remain persistent, all messages on a connection MUST > have a self-defined message length (i.e., one not defined by closure > of the connection), as described in Section 3.3. > > So no keepalive is possible if the message length (content-coding) is > undefined. Correct. It is NOT kept alive by the client (httpd) in this proxy case. But (to Jim's statement) the next-hop server claims it *is* kept alive and will handle the socket as kept-alive... > That could be a valid HTTP response : > > HTTP/1.1 200 OK > Transfer-Encoding: x-cleverness > Content-Length: 1000 > > but still the C-L must be ignored by the receiver, and a > read-until-close be used by it. [Thank you for correcting me, the issue at hand is strictly with proxy response body processing in the first place.] Because the server claims it is keep-alive. It will send its thousand bytes (decorated by whatever x-cleverness might frame it with), and will then enter a keepalive loop. WE won't enter a keepalive loop, because we won't reuse the connection. But the next-hop server is keeping it alive for whatever duration it believes it should be waiting for the next request from the client (httpd). And in the interim, we are hung and holding our client's response open. At best you can describe this as a waste of worker requests, and at worst, as a mild DoS. We need to perform a lingering close (reading until our read end was closed by the next-hop server). The question is whether we tolerate the forwarding of keep-alive, other-than-'chunked' T-E proxy responses? By closing our write-end of the connection, we can signal to the server that we can't efficiently forward their response to the client (owing to the fact that the server believes this to be a keep-alive connection, and that we can't know where this specific response ends, until the server has given up on receiving another keep-alive request). My vote on this patch right now is -0. I don't believe it must be applied to 2.4.x this moment for this coming release and would prefer that we alter the behavior as of a specific release, not incrementally across several different releases (e.g. 2.4.6 w/ old behavior, 2.4.7 with an interim behavior and 2.4.8 with yet a third behavior). But I won't block the patch further if it has the votes for backport now.
