Re: [PATCH] send HTTP/1.1 requests to HTTP servers for selected requests

mån 2010-03-01 klockan 14:46 -0700 skrev Alex Rousskov:

> in hope that it would be useful for Squids that default to HTTP/1.0 and
> those that default to HTTP/1.1. I am not sure we will ever need to
> downgrade to HTTP/1.0 but it is certainly possible, especially if we
> default to HTTP/1.1 (is not such a default a violation of RFC 2616?).

In what way would our client advertising itself as HTTP/1.1 to clients
be a violation in the 3.1 code base?

We can't yet advertise ourself as HTTP/1.1 to clients, due to many small
things such as chunked encoding, 100 relaying etc missing, but this is
of little effect on what version we advertise our client as.

> > I've thought something like
> >
> > no_http_version_upgrade <number> <acl-list>
>
> Please do not add no not positive options. No_cache was confusing enough
> :-).

Agreed.

What about

http_version <number> <acl..>

plus for trunk similar http_version= option to http(s)_port but without
acl..

> > But don't really seen the need for it yet. The brokenness seems to be
> > all in servers wanting a higher version sent to them. Not a lower.
>
> Right, but this could be because we are not sending higher versions yet.

The only things I know of seen with 2.7 running with HTTP/1.1 on both
sides have been

- 417 broken clients
- chunked encoding in requests

But then 2.7 also filters forwarded requests somewhat. Mainly Expect and
TE IIRC.

but the available test data is admittedly not very huge, just a couple
of minor ISPs..

The 417 brokenness is not related to which protocol version we announce,
but just broken clients not prepared to deal with unfulfilled
expectations..

If we do nothing about Expect then we will behave the same as Squid-2
configured with "ignore_expect_100" which is the way we currently
behave.. change of protocol versions do not change this aspect at all.

Regards
Henrik
Received on Mon Mar 01 2010 - 23:06:07 MST