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. > > STUFF /thisaction HTTP/1.1 > Transfer-Encoding: x-cleverness > Content-Length: 1000 > > was a perfectly valid body, but if we drop C-L, and will pass the > thousand bytes and sit indefinitely in an HTTP/0.9 body handling > loop waiting an indeterminate amount of time for the close of the > stream (which isn't immediately forthcoming) something is busted. > This is not a valid HTTP request, the T-E must end with "chunked". And if it were the case, the C-L must be ignored by the receiver. 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. > And I'm not claiming existing behavior was any more correct :) > >
