[squid-users] Re: R: [squid-users] HTTP/1.0 417 Expectation failed

From: Henrik Nordström <henrik_at_henriknordstrom.net>
Date: Mon, 22 Feb 2010 11:20:20 +0100

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
Received on Mon Feb 22 2010 - 10:20:30 MST

This archive was generated by hypermail 2.2.0 : Mon Feb 22 2010 - 12:00:05 MST