RE: Redirection MUST NOTs

Well, that good reason should be user authorization. Obviously you could
remember this authorization for that specific redirect.

What you basically don't want to happen is your POST or PUT going to a
different site. I couldn't imagine someone wanting to do this anyway.
This is also the reason why browsers warn (and they should be doing this)
when switching secured/unsecured.
This is where the potential hazard is, commonly with authentication, using a
secure site and the rest on a unsecured site. These redirect from secure to
unsecure and I don't want this to happen with my POST containing my
authentication information.

Perhaps the definition:
On retreiving .... the user agent MUST NOT automatically redirect when
sending data, such as POST, PUT or web authoring functions and SHOULD NOT
automatically redirect otherwise, unless the request is GET or HEAD, in
which case a browser MAY redirect.

Still, I'm interested in a (practical) sitiation where one needs to redirect
a non-GET/HEAD request?

- Joris

> -----Original Message-----
> From: 
> [] On Behalf Of Mark Baker
> Sent: Tuesday, 4 November 2003 22:04
> To: David Morris
> Cc:
> Subject: Re: Redirection MUST NOTs
> On Tue, Nov 04, 2003 at 11:00:42AM -0800, David Morris wrote:
> > 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.
> Not at all.  My proposal doesn't require that any client 
> change behaviour (as they'd still conform to a "SHOULD NOT" 
> requirement).
> It just asks that new clients be permitted to auto-redirect 
> if they have a very good reason to do so.
> Mark.
> -- 
> Mark Baker.   Ottawa, Ontario, CANADA.

[Hopefully not going anywhere or duplicated. Still had the old WG mail
address @ listed.]

Received on Tuesday, 4 November 2003 16:43:43 UTC