- From: David W. Morris <dwm@xpasc.com>
- Date: Fri, 1 Aug 1997 11:59:30 -0700 (PDT)
- To: Ben Laurie <ben@algroup.co.uk>
- Cc: Larry Masinter <masinter@parc.xerox.com>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
On Fri, 1 Aug 1997, Ben Laurie wrote: > Larry Masinter wrote: > > satisfies all of the requirements that are MUST for 1.1, then you > > need to label the response as 1.0. > > OK. It still seems to me that the correct thing to do is to fix CGI. A > simple thing to do would be to add a version header: > > CGI-Version: 1.1 (nb., this suggestion mixes CGI and HTTP versions ...) > > Absence of the header means the script is 1.0 compliant. This is not an > HTTP header - the server would strip it, I assume, and doctor other > headers as needed. I think this issue is much larger than whether the server know that an individual CGI script complies with HTTP/1.1 in what it generates. This just as easily fixed with out band server configuration choices. As a separate subject, it may be appropriate for some group to standardize the CGI API and include a version, but that isn't our task and such a change won't help this problem... If a script was written to empirical behavior, it (actually, the target being referenced) may expect a 302 response to POST to return as a GET. That server may be accessed by a proxy which changes the HTTP status line version to 1.1 making any necessary updates to header fields. If a *client* which sees the 302 status on what is marked as an HTTP/1.1 response adopts rigid 302 handling, an existing HTTP/1.0 server/application will break. Who gets blamed? It works with my old browser (still if I re-install it, etc.) and not the new one. In the user's mind the blame rests with the browser, not an out of date server. The 307 proposal works. Lets do it. Dave MOrris
Received on Friday, 1 August 1997 12:01:49 UTC