- 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
>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. ....Roy
Received on Friday, 5 September 1997 13:50:16 UTC