W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

Re: #328: user Intervention on Redirects

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 07 Feb 2012 16:14:43 +0100
Message-ID: <4F313FE3.2060302@gmx.de>
To: Mark Nottingham <mnot@mnot.net>
CC: HTTP Working Group <ietf-http-wg@w3.org>
On 2012-02-07 00:55, Mark Nottingham wrote:
> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/238>
>> The redirect status codes define requirements for user intervention; e.g.,
>> If the 301 status code is received in response to a request method that is known to be "safe", as defined in Section 7.1.1, then the request MAY be automatically redirected by the user agent without confirmation. Otherwise, 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.
>> However, this requirement is not often implemented by UAs.
> I'm now wondering if we should consider removing this requirement altogether.
> The way it's structured now, the requirement associates intent with a URI, when in reality intent is associated with the UI; the user is blissfully unaware of the actual resource being manipulated.
> More to the point, there's little to no difference between an HTML form POSTing somewhere and getting redirected somewhere else to the form just using the second URI in the first place.
> I think this requirement is well-intentioned, but the threat model of the Web has changed significantly since it was written.
> Thoughts?

1) Remove the statements from 301/302/307.

2) In a single place, explain the risks of automatically redirecting 
when the new request method is unsafe. Note this applies to *any* kind 
of following redirects, including future ones (such as 308).

Not sure about where to put the text for 2); does this belong into the 
description of 3xx or into the Security Considerations?

Best regards, Julian
Received on Tuesday, 7 February 2012 15:18:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:00 UTC