Re: Redirection MUST NOTs

What you propose requires a change to client behavior in a way that
potentially reduces the integrity of the user interaction for all sites
because you have a specific site you believe has a valid reason for
allowing handling the redirect w/o user interaction.

I don't believe endorsing this change in client behavior would be a good
idea. Adding a new header or header parameter which declared a server's
good intentions might be a reasonable approach. The client designers could
then choose to honor the declaration or perhaps prompt the user once and
remember that a specific server was approved, etc.

Dave Morris

On Mon, 3 Nov 2003, Mark Baker wrote:

> Hi,
> In the descriptions of each of the 301, 302, and 307 response codes of
> RFC 2616, the following text can be found;
> "If the [code] status code is received in response to a request other
>  than GET or HEAD, the user agent MUST NOT automatically redirect the
>  request unless it can be confirmed by the user, since this might
>  change the conditions under which the request was issued."
> I believe that the conformance level should be "SHOULD NOT" rather than
> Though I'm not familiar with the history of this requirement, it seems
> self-explanatory regarding its intent; it's there as a warning, not as
> a conformance statement.  And while it's certainly the best approach
> in the generic case (as "SHOULD NOT" would indicate), the opportunity
> for a private agreement to exist between client and server should be
> recognized IMO.
> In my case, the nature of the type of resource - as indicated in the
> messages via link metadata - to which a POST is submitted is such that
> there is no change of condition under which the request was issued.  The
> agent has committed to submitting the data across a trust boundary with
> the expectation that a redirect is being performed in lieu of the server
> acting as an intermediary for the request.
> Thanks.
> Mark.

Received on Tuesday, 4 November 2003 14:20:01 UTC