tis 2010-03-02 klockan 00:06 +0100 skrev Henrik Nordström:
> 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?

to servers I meant.. in case not obvious

> 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

Reply via email to