Re: On the abuse of chunking for interactive usages

that behaviour should be strongly discouraged.

It will break on anything that

a) re-chunks the data stream (e.g. due to nagling etc)
b) spools data streams
c) has plug-in filters that do things

The client and server have to treat the entire message as the entire 
message.  There's nothing can be guaranteed about the timing of parts of 
a message.  To rely on such a thing is therefore worse than foolhardy, 
since it creates problems for intermediary implementors when the 
customer says "it works fine without the proxy", and creates pressures 
on intermediary implementors to compromise security and features to deal 
with a broken application.

just my 2c.  It will certainly break through WinGate, especially with AV 
installed.

Regards

Adrien


On 11/05/2011 10:29 a.m., Willy Tarreau wrote:
> On Tue, May 10, 2011 at 03:13:06PM -0700, Brian Pane wrote:
>> I can imagine variants of Willie's use case that happen even in the
>> absence of chunking: an origin server receiving a large file upload
>> might attempt to stream back a response "10% complete ... 20% ..."
>> incrementally.
> yes that's one valid point.
>
>>   Thus I think the general issue is:  Should a
>> proxy be allowed to (or prevented from, or perhaps even required
>> to) stream a request though toward the origin server before it
>> receives the entirety of the request?
> Well, we can't prevent a proxy from doing so because we can't require
> it to buffer all the response. We can't make it mandatory to do so
> either because some proxies will need to analyse everything before
> letting the request pass (think webmails + anti-virii). So we must
> only let them do what they feel right for what they do. In fact there
> is a large spectrum of possibilities depending on the usage.
>
>> I think the "allowed to" option is the most pragmatic approach.
> Indeed.
>
>> There are proxies that have good reasons for buffering the entire
>> request body (ease of implementation, scanning of POST payload
>> for malicous input), and there are proxies that have good reasons
>> for not buffering the request body (minimization of memory usage,
>> denial-of-service avoidance).  It seems prudent to let each
>> implementor decide what tradeoffs are best for their implementation.
> Exactly. My concern is not with proxies, as I think they all have valid
> reasons to act as they do (and difficulty to implement support for either
> method is a valid reason too in my opinion). My concern is with people
> spending time inventing protocols that will not be able to work on top of
> 100%-compliant proxies. There surely is something that can be done so that
> those people don't waste their (nor their users') time implementing and
> deploying something which will break once widely deployed.
>
> And since it's not the first time I read suggestions of such a way of
> turning HTTP into a full duplex link, I think there is room left for
> ambiguity. It has even been evocated on the hybi ML several months ago.
> And a decade ago I used to abuse squid's interactive handling of POST
> to telnet home from customers' so I can't blame implementors for trying
> to use the protocol that way :-)
>
> Regards,
> Willy
>
>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Tuesday, 10 May 2011 22:42:39 UTC