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
