mån 2010-02-22 klockan 10:25 +0100 skrev Riccardo Castellani: > But, if you see RFC2616 for proxy, there is no reference about to consider > proxy server as next hop. RFC 2616 says that proxy forwards request > according to next hop (if next hop is or it's not compliant to HTTP/1.1). > I think proxy, even if it compliants with HTTP/1.0, should have only to > examine the next hop without taking care of itself (that is like http > protocol 1.1 -1.0) > You correct me if I wrong... Well, it's an approximation of the current functionality of Squid-2.7. As it supports HTTP/1.1 both as a server and as a client, but can't forward HTTP/1.1 yet Squid consider itself to consis of three parts.. http/1.1 server accepting request, internal HTTP/1.0 proxy forwarding data, and http/1.1 client making outgoing requests. The wordings in RFC2616 do not consider cases where something is almost HTTP/1.1. If you want an exact fit for RFC2616 then consider the following case client -> HTTP/1.1 proxy -> HTTP/1.0 proxy -> Webserver This will always result in 417 if you try using Expect: 100-continue as the HTTP/1.1 proxy is required to do so. The thing is that any intermediary server implemented per RFC2616 and receiving Expect: 100-continue and knowing that the expectation can not be fulfilled MUST return 417. The text you quote is more examples of cases where this need to be done than the full description. My question to you is why are you upset about Squid returning 417 when it knows it can not fullfill your expectation? What is the problem with handling 417 responses? And why are you sending "Expect: 100-continue" if you are not also prepared to handle the 417 responses that expectation may result in? Regards Henrik
