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

Re: RE-VERSION

From: Foteos Macrides <MACRIDES@sci.wfbr.edu>
Date: Mon, 11 Aug 1997 11:25:52 -0500 (EST)
To: fielding@kiwi.ics.uci.edu
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <01IMB881068I007XQW@SCI.WFBR.EDU>
"Roy T. Fielding" <fielding@kiwi.ics.uci.edu> wrote:
>>> in the response chain, how about the following compromise:
>>> 
>>>    Follow the existing versioning requirements as-is, except that if the
>>>    request is HTTP/1.0 (and only HTTP/1.0), then make the response HTTP/1.0.
>>
>>and this is for proxy, server or both?
>
>Both.

	That's a bit more than a compromise.  It's abandoning the ability
of a UA to use HTTP/1.0 in requests and then size up the situation based
on HTTP/1.[> 0] in responses.  The shortcut of old HTTP/1.0 proxies acting
as true proxies for the request, but like a tunnel for http server responses,
is unfortunate, though understandable.  During the transition from so-called
HTTP/0.9 (body only) to HTTP/1.0 (status line and headers), the response
might or might not have included more than a body, and so parsing it for
a status line which if present would have HTTP/1.0 and not be changed
seemed like pointless overheader and vulnerability to a parsing foul
up.  In the transition from HTTP/1.0 to HTTP/1.1, it is not pointless,
and the proxy implementers forgot that they had taken a shortcut, or
where not around during that first transition and didn't infer that a
shortcut, rather than overt compliance with the versioning requirement,
had been taken.  It also won't help with already deployed HTTP/1.1 servers.
It seems better to stick with the OPTIONS probe, make unmistakeably clear
in the comments/explanations sections of the HTTP/1.1 RFC, itself, that a
proxy is expected to use its OWN, both major AND MINOR, version in both
the request AND RESPONSE directions, make clear the reasoning for that,
and explain use of the OPTIONS probe with the hope that in a year or two
or three it won't be needed any longer for old, non-compliant HTTP/1.0
servers/proxies.

	As far as "UAs that originate a request, e.g., browsers" are
concerned, it's risky to chunk a POST submission even if it's known
that only compliant HTTP/1.1 servers/proxies are in the request chain
(the origin server might not "put it all together and determine a
Content-Length" before invoking a CGI script), and for PUT, that
would act equivalently to an OPTIONS probe, wouldn't it?

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================
Received on Monday, 11 August 1997 08:28:22 EDT

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