Re: RE-VERSION

Klaus Weide <kweide@tezcat.com> wrote:
>On Sun, 10 Aug 1997, Foteos Macrides wrote:
>
>> 	In an earlier round of discussions about this, when that false
>> claim was checked against reality, and the consequent problem of it
>> leading to inappropriately chunked POSTs was raised, the suggested
>> workaround kludge was your second, i.e., for the client to send an
>> OPTIONS request, and proceed with the chunked POST only if it doesn't
>> get back a 400 from the broken proxy.  That'll work with the CERN proxy,
>> but I don't know about Squid, or if any other proxies are similarly broken
>> in reality (from Josh's original message, it seems likely the Netscape
>> proxy also passes through the origin server's status line for the response,
>> without changing the minor version number to it's own).
>
>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.

	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 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)?

				Fote

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