- 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
"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 UTC