- From: John Franks <john@math.nwu.edu>
- Date: Thu, 4 Sep 1997 09:30:31 -0500 (CDT)
- To: Foteos Macrides <MACRIDES@sci.wfbr.edu>
- Cc: josh@netscape.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
On Wed, 3 Sep 1997, Foteos Macrides wrote: > Josh Cohen <josh@netscape.com> wrote: > >So, am I correct in saying that the new CGI must check the version > >of the *REQUEST* before deciding which code to send back ? > > Yes. > I think Roy's point was that this will not work in the presence of proxies. He points out that proxies are not allowed to change status codes. Because of the hop-by-hop nature of versioning, the server has no idea what version the client is using -- it only knows the version of the nearest proxy. It can send a 303 based on this proxy being 1.1, but proxies are not allowed to change status codes, so the 303 may go all the way back to the (perhaps 1.0) client which may not understand it. Perhaps I am missing something, but I see no way to safely send a 303 (or any other status which 1.0 clients don't understand, if there are any) in the presence of proxies. > > >I assume that SERVER_VERSION is the server version, not the request > >version. I dont have the CGI stuff in front of me, is there > >a variable to tell the CGI script what the request version was ? > > Heaven help us who are typo prone (and particularly those of > us who are getting old and senile :). That's SERVER_PROTOCOL, and > it's whatever HTTP/major.minor version the browser, itself, claimed > in its request. > Yes, so SERVER_PROTOCOL is the *request* protocol version and may be completely different from the *server* protocol version. (Sigh). John Franks Dept of Math. Northwestern University john@math.nwu.edu
Received on Thursday, 4 September 1997 07:35:55 UTC