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
