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
=========================================================================