Re: On the abuse of chunking for interactive usages

Hi Poul-Henning,

On Tue, May 10, 2011 at 09:45:16PM +0000, Poul-Henning Kamp wrote:
> In message <20110510212615.GA504@1wt.eu>, Willy Tarreau writes:
> 
> >My concern comes from this specific use of chunking. I see no reason why
> >this would be valid. I know it will not work at many places. Some proxies
> >(such as nginx IIRC) buffer the complete request before passing it on.
> 
> Well, it doesn't say anywhere in RFC2616 that "A server SHALL NOT
> reply until it has received the entire request including the body,
> if any.", so from a standards point of view, it is not "invalid".

It's not the fact that the server replies earlier which is a concern
to me, as anyway it's allowed to do so (eg: redirect, 401, etc...).
It's the fact that both ends agree that they're free to do whatever
they want on the TCP connection despite of the messaging rules.

> But we can readily agree that it will probably come as a major
> surprise to most readers of RFC2616 that anybody would do this.

As well as I'm sure that the implementers did this in good faith, they
probably didn't notice anything clearly stating it's not intended to
work. And the worst we can do is to have two incompatible designs both
justify their choices based on the same spec (though I'd argue that once
you read all RFC2616 you get the general idea that HTTP is not meant to
be used that way).

> And most HTTP proxies (as opposed to HTTP load-balancers) will
> not permit it through at all.

Indeed.

> You can configure Varnish to let this through:  Varnish has a
> "pipe" mode, where after the first request on a TCP connection has
> been passed to the backend, varnish just moves bytes forth and back.

It's the same in haproxy, the old mode which I renamed "tunnel mode"
did only analyse the first request and response of each TCP connection.
I'm pretty sure that many HTTP intermediaries started that way because
it's not too hard to do and it covers many usages. But I now want to
divert users from that mode because it's incompatible with keep-alive
and is not particularly secure.

> But that is merely a reflection of my "code, not policy" attitude
> to software tools, I agree with you that this should be discouraged
> as much as possible.

Any code more or less indicates a trend and usage. After all, many
items listed in the draft come from observations of what has been
implemented.

Thanks for your feedback, it's really valuable and useful to me, it
comforts me in the idea that I'm not the extremist guy on the subject
(or not the only one :-)) and that there are huge chances that such a
project experiences many similar or worse issues in the future. So I'm
still thinking I won't change the default behaviour but I'll add an
option to let such users have the performance they're expecting.

Regards,
Willy

Received on Tuesday, 10 May 2011 22:00:09 UTC