Re: HTTP/1.1 to clients in 3.1.2?

Alex Rousskov wrote:
> On 05/01/2010 09:35 AM, Henrik Nordström wrote:
>> lör 2010-05-01 klockan 08:55 -0600 skrev Alex Rousskov:
>>
>>> Chunked requests: The current buffer-and-forward code is probably
>>> compliant. It is also inefficient and limits the size of the request,
>>> but I doubt that violates the standard.
>> buffer & forward with content-length in itself do not violate the
>> standard, but interacts badly with 100 Continue requirements.
>
> Good point.
>
>> Also, what happens when the buffer is full (request size over limit)?
>
> IIRC, we respond with an error.
>
>> And do the code deal properly with eating any pending request data when
>> Squid responds with an error?
>
> Do not know.
>
>> And that dechunk code is in itself a DoS vector, because it buffers
>> before access controls. The default limit of 64KB per connection is
>> somewhat manageable, but also quite small
>
> Agreed. We have seen users forced to configure the buffer size to be
> 640KB, with plans to use 1MB setting. There are some popular mobile
> applications that need that, apparently.
>
>
>> And right that's the other blocker for announcing 1.1 towards clients..
>> passing of 100 Continue messages and handling of 1xx messages in
>> general.
>
>> Announcing 1.1 without supporting 100 Continue may cause some clients to
>> wait indefinitely when trying to send request entities. The timer
>> suggestion is only when not knowing if the next hop is 1.1. But probably
>> the major browsers always implements the timer (not tested).
>>
>> And always sending 417 Expectation failed in response to Expect:
>> 100-continue is known to break other clients...
>>
>> Looking at the code. Ok. default is to not ignore Expect: 100-continue
>> and respond with 417 which takes care of the timer worry above, unless
>> one needs to configure Squid to ignore 100-continue. And as seen in
>> squid-users discussions there is a significant population of broken
>> clients wrt 100-continue & 417 handling so this can be expected to be
>> configured in many setups.
>
>
> It sounds like we should revert the advertising change for now and go
> back to the force_http_1p1_response patch that, IIRC, triggered this
> whole discussion and the advertising change. What do others think?
>
> Alex.

The 100-continue stuff is identical to 2.x treating requests as passing
over a known HTTP/1.0 step internally, with an override to prevent
broken clients getting the 417.
It's been running in 2.7 and 3.1.1 already. The result seems to be that
several app builders and clients have noticed and the apps are starting
to get fixed.

I was under the impression that chunked decoding was sufficiently
working since the early 3.1 betas. If that is incorrect I'd rather see
it fixed ASAP, but can handle a revert while that happens if we can
actually identify a breakage here.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.1