- From: Foteos Macrides <MACRIDES@sci.wfbr.edu>
- Date: Wed, 03 Sep 1997 20:06:03 -0500 (EST)
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Josh Cohen <josh@netscape.com> wrote: >Ok, lets assume for the moment that we adopt the 307 proposal. >(hypothetically).. > >Now, Im joe CGI script writer, and Im writing a new CGI script. >I want to make the client do the "redirect with GET behavior". >So, I read the spec and figure out what to do. Whether you can figure out what to do from the spec will depend on whether it's written with an adequate understanding of the implementation issues and an earnest concern for interoperability and backward compatibility. If it has one speech for a Mountain View audience in Section 5.2 and another speech in the Appendix for a Bible Belt audience, then no, it won't be clear what to do. But we can hope for better this time. >Hmm.. 302 is deprecated, so I shouldnt use that. It is deprecated in HTTP/1.1, not HTTP/1.0. >Ahah! 303, thats what I want.. That's an HTTP/1.1 status code, not present in HTTP/1.0. >So, I code my script to respond with a 303, confident that the > client will come back with a GET for the location: I specify. > >NOPE. >90% of the browsers today dont support 303 (yet). >If this isnt backwards incompatible, what is? > >So, I could either: > 1) send 302, ( yeah it says 'deprecated', but it will live forever, > it will never be 'safe' to send 303 ) > > 2) only send 303 if the request was HTTP/1.1 >This gets ugly.. This is "bogus". "You must not have read the proposal." Why do you suppose CGI has a SERVER_PROTOCOL variable?!? If that variable has a value of "HTTP/1.1" you should be able to send 303 with 100% confidence that the browser will switch to GET, or 307 with 100% confidence that it will retain POST. If the value is HTTP/1.0, you should not send 303, nor 307, because they are not defined status codes for HTTP/1.0. In that case, you can send 302 with at least 99% confidence that the UA with switch to GET, because only Lynx v2.6 (as far as I know, perhaps there are some others) respected the HTTP/1.0 specs on that matter and retains POST, and hopefully much less than 1% of the Web is still using old versions of freeware. If the SERVER_PROTOCOL value is HTTP/1.1 and you do send 303 but the browser doesn't switch to GET, or 307 and it doesn't retain POST, then that browser was written incompetently -- not according to the HTTP/1.1 specs it claims to support -- and the user should get a better browser (act as a "market force" in the old, non-doublespeak meaning of that term :). >It seems to me that the "swap" proposal only leaves an ambiguous > case, with the potential to fail for implementations who > follow the 'interim spec' (prior to the swap), but remains > mostly functional with 90% of the existing browsers. > >The "307" proposal, will allow currently functioning CGI > scripts to continue to work, but it will be a very long > time until a CGI implementor can feel comfortable with > returning a 303. The "307" proposal will allow CGI scripts to work with at least 99% probability of success with both HTTP/1.0 and HTTP/1.1 browsers. Think about it some more. Try it, you'll like it!!! :) :) Fote ========================================================================= Foteos Macrides Worcester Foundation for Biomedical Research MACRIDES@SCI.WFBR.EDU 222 Maple Avenue, Shrewsbury, MA 01545 =========================================================================
Received on Wednesday, 3 September 1997 17:12:11 UTC