Re: [squid-users] Understanding Expect 100 default setting

tor 2008-12-04 klockan 11:45 +0000 skrev Paul Cocker:

> What I'm looking for is a brief, technical explanation of why this
> setting defaults to off rather than on. I didn't really get from that
> thread why the defaults were the way they were, especially as the
> behaviour described with the Expect 100 wasn't in violation of spec,
> just unusual.

Sending Expect: 100 in an request is encouraged by the RFC, but the
applications doing this SHOULD be prepared to see 417 Expectation Failed
responses due to the expect and then retry the request without the
expectation.

The reason for this in HTTP is because the 100 Continue interim response
code is a new feature in HTTP/1.1 and only supported in HTTP/1.1. If
there is HTTP/1.0 paths involved or even most HTTP/1.1 proxies knowing
the next hop is HTTP/1.0 or otherwise not capable of forwarding 100
Continue responses then the only way of telling the client that 100
Continue won't be seen is by rejecting the request with a 417
Expectation Failed response.

The 417 Expectation Failed message really is

"Sorry, you said you want to see a 100 Continue response before sending
the rest of the response. Due to various reasons 100 Continue can't be
supported here. Please retry the request without expecting a 100
Continue response".

Now the dirty parts.. As Expect also wasn't known until late HTTP/1.1
(RFC2616) clients who use this should also handle the silent case that
the Expect header is ignored, just as they did in HTTP/1.0 or early
HTTP/1.1.. Because of this it in most cases works to simply ignore the
100 Continue expectation, but there is no guarantee as the HTTP/1.0
woraround is both optional and only applies when the client may suspect
there is HTTP/1.0 hops in the request path..

> We had a problem which was solved by this setting, and I want to be in a
> position to explain why things were setup in a way which caused this
> issues to occur.

In short, caused by a slightly broken client who can't deal properly
with HTTP/1.0 hops in the request path, failing the request instead of
retrying without the expectation when seeing a 417 response.

Unfortunately this isn't spelled out clearly enough in RFC2616 unless
you cross read the client requirements with the proxy requirements.

Regards
Henrik
Received on Sun Dec 07 2008 - 11:02:59 MST