W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1997

Re: RE-VERSION

From: Klaus Weide <kweide@tezcat.com>
Date: Mon, 11 Aug 1997 13:25:17 -0500 (CDT)
To: Foteos Macrides <MACRIDES@sci.wfbr.edu>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <Pine.SUN.3.95.970811125128.15980B-100000@xochi.tezcat.com>
On Sun, 10 Aug 1997, Foteos Macrides wrote:
> Klaus Weide <kweide@tezcat.com> wrote:
> >Well, it (Squid 1.1.1) doesn't give a 400 response, but the response
> >definitely makes clear that this is no HTTP 1.1 server :)
> >Actually any response to OPTIONS which does not start with a valid
> >"HTTP/1.1" (or higher) Status-Line should be enough to discredit a
> >proxy's previous response with such a version.
> 
> 	OK.  I don't know what's the proper terminology, but in effect
> it's punting down to an HTTP/0.9 response, so if the UA uses the rule,
> "Assume an old, non-compliant HTTP/1.0 proxy is interposed if you don't
> get back a 200 status.", the OPTIONS probe should work.

It need not be a 200 status - any "HTTP/1.N" response with N>0 would
be sufficient to detect that a next-hop server is not one of those proxies.

My understanding is that no HTTP/1.1 server is required to implement
any specific method.  (So it could still be compliant if it responded
to all methods with "HTTP/1.1 405 Method not allowed" or "HTTP/1.1 501
Not Implemented".  Of course that's not very useful.)

> 	Your example, in another message, of a UA which sends a "minor
> = n" request but wants to know if it can use any "minor > n" functionality
> which it has implemented thus far is a very realistic case, and gets at
> the reasoning behind the versioning rules (based on my recollections of
> previous outbreaks of these debates :), so I agree with John that it would
> help to spell out that reasoning rather than leaving it in a "That goes
> without saying, dummy!" category.  That's the case which is most
> problematic when an old HTTP/1.0 proxy is interposed and passes through
> an origin server's HTTP/1.[> 0] response status unmodified.  

If you mean that an old HTTP/1.0 proxy is more problematic for a
"halfway there" HTTP/1.0 UA than for a HTTP/1.1 UA, then I don't
understand why.  I think such a proxy could screw up more things
in a   
            HTTP/1.1     <->  HTTP/1.0(noncompliant)  <->  HTTP/1.1  
chain than in a
         HTTP/1.0(+1/2)  <->  HTTP/1.0(noncompliant)  <->  HTTP/1.1  
chain.

> If you get
> back Connection: close, you don't know if it's a direct response to your
> HTTP/1.0 request, so you can't avoid the overhead of an OPTIONS probe.
> If the UA did send an HTTP/1.1 request, then it could infer that something
> is fishy.  Is there a reason to worry about these things in HTTP/1.1
> except in the case of chunking (though that's an enhancement hoped to
> be widely implemented ASAP, so I don't intend to minimize the issue)?

I don't understand the "Connection: close" example - specifically why
getting back a "Connection: close" would indicate fishiness.
fishiness.  As far as I understand any HTTP/1.1 server can send this
in the response to any HTTP/1.1 request, although normally they don't
(at least for the first one on a new connection.)


        Klaus
Received on Monday, 11 August 1997 11:26:35 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:51 EDT