Klaus Weide <> wrote:
>On Sun, 10 Aug 1997, Foteos Macrides wrote:
>> Klaus Weide <> 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  
>> 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.)

	I was addressing the suggestion that a new header (not easy
in LAST_CALL) or simple analyses of existing HTTP/1.1 headers, might
help avoid the overhead of sending an OPTIONS probe simply to check if
a non-compliant HTTP/1.0 proxy is interposed.  Those proxies do send
HTTP/1.0 in the request direction, so you would expect Connection: close,
and never Transfer-Encoding: chunked in an HTTP/1.1 origin server's
response for a document that includes a form.  However, if the UA used
HTTP/1.0 rather than HTTP/1.1 in its request, that would be expected
anyway, so you have no additional information about the situation.

	As far as getting back 405 or 501 because that's possible based
on What is Written, I thought we were in LAST_CALL for moving HTTP/1.1
from Proposed Standard to Draft Standard, hoping to catch any potentially
serious implementation problems, and interpretation of the Word is not my
forte. :) :)


 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545

Received on Monday, 11 August 1997 12:59:01 UTC