W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 1997

Re: 301/302

From: Roy T. Fielding <fielding@kiwi.ics.uci.edu>
Date: Fri, 05 Sep 1997 13:35:25 -0700
To: John Franks <john@math.nwu.edu>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <9709051342.aa10813@paris.ics.uci.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4346
>I hope I am wrong, but we seem to have painted ourselves in a corner
>here.  On the one hand we have decided that the client's version
>should not be communicated to the origin server when there are proxies
>(all version information is hop-by-hop).  And on the other hand we
>have created end-to-end headers (e.g. 303/307) which are not
>reasonably handled by HTTP/1.0 clients.  It seems that if there is no
>end-to-end version information we can't have new end-to-end headers
>that will break on HTTP/1.0 clients.

There is no hard boundary between HTTP/1.0 and HTTP/1.1.  303 and 307
are HTTP/1.0 status codes just as much as they are HTTP/1.1 status
codes.  The HTTP version number completely ignores such differences
because to do otherwise would lead to passing around the equivalent
of feature sets on every single transaction.

The Via header field provides all that is necessary to determine the
minimum supported protocol along the request route, but that isn't
going to tell you whether or not a particular status code is implemented
optimally in a particular application.  During times of instability,
new implementations will have to work around older implementations if
they are looking for optimum results, but that is a small price to pay
in exchange for the increased capabilities when new implementations are
working with other new implementations.  Only time and stable specs will
reduce the need for workarounds.

Received on Friday, 5 September 1997 13:50:16 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:03 UTC