Bert Freudenberg <[EMAIL PROTECTED]> wrote:
> > Finally, the RFC does provide a specific method for redirect-using-GET,
> > and that is response code 303. Here that one case that Squeak gets
> > wrong: it treats 303 and all other 3xx responses identically. Instead,
> > Squeak should continue to redirect the basic 301, 302, and 307 responses
> > as POST's (after asking the user, ideally), but it should be changed to
> > redirect 303 as a GET.
>
> Well, even the W3C recognizes the "302 redirects to GET" behavior as
> de-facto standard, and invented the 303 and 307 codes:
>
> However, most
> existing user agent implementations treat 302 as if it were a 303
> response, performing a GET on the Location field-value regardless
> of the original request method. The status codes 303 and 307 have
> been added for servers that wish to make unambiguously clear which
> kind of reaction is expected of the client.
>
> So I'd say Squeak should follow the crowd here, since it only claims to be
> HTTP/1.0 compliant anyways. That means silently redirect POSTs to GETs for
> 302/303 and redirect 301/307 POSTs to POSTs if the user confirms.
>
Hmm, even the HTTP 1.0 spec says that you should not truncate a 302
response to GET:
> Note: When automatically redirecting a POST request after
> receiving a 302 status code, some existing user agents will
> erroneously change it into a GET request.
Anyway, let's remember that this isn't just a matter of compatibility.
If we silently truncate a POST to a GET, then we will make correct
servers stop working! It seems we must choose between supporting
correct servers or incorrect ones, and we can't seem to do both (short
of asking the user on a server-by-server basis).
IMHO, given this unhappy choice, let's support the correct servers. The
incorrect ones will be fixed eventually, if they are being maintained at
all.
Lex
