Re: User confirmation and 307 redirects

On Aug 19, 2010, at 10:29 AM, Adam Barth wrote:

> On Thu, Aug 19, 2010 at 2:49 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
>> thanks for the reminder. This needs to be tracked.
>> 
>> On 18.08.2010 23:27, Adam Barth wrote:
>>> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-11#section-8.3.8
>>> says
>>> 
>>> [[
>>>    If the 307 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.
>>> ]]
>> 
>> Note: 301 and 302 have the same requirements.
>> 
>>> As has been pointed out by multiple folks on multiple occasions, this
>>> requirement should be removed for the following reasons:
>>> 
>>> 1) HTTP ought not to impose constraints on the user agent's user
>>> interface.  This requirement is not appropriate for all user agents,
>>> for example a GPS navigation unit in a car.
>> 
>> Question for clarification: what kind of unsafe methods would you expect
>> that unit to make?
> 
> POST requests, e.g., to send traffic data to the server.
> 
>>> 2) This requirement does not reflect reality.  A number of widely used
>>> user agents disregard this requirement.
>> 
>> That doesn't *necessarily* mean that the requirement is wrong.
> 
>> From the charter:
> 
> [[
>  * Remove or deprecate those features that are not widely implemented
>  and also unduly affect interoperability
> ]]
> 
> This feature is widely not implemented and unduly affects interoperability.

It isn't a feature.  It is a security constraint.  The fact that some
browsers have security holes is well known.

>>> 3) This requirement is actively harmful to interoperability.  Web
>>> sites cannot reliably use 307 redirects because it triggers awful UI
>>> mandated by this requirement in some user agents.
>> 
>> That would be a problem, indeed. (Context: Opera follows the requirement for
>> 307, but not for 302).
>> 
>> For this discussion, it would be interesting to see an example for a POST
>> being redirected.
> 
> These examples are rare on the public Internet because of the lack of
> interoperability and the ugliness of the UI requirement.  However,
> when Chrome has a UI dialog, we received bug reports from folks about
> intranet sites that popped up the dialog (because most of their users
> where using IE, which omits the dialog).  I then removed the dialog,
> and we've lived happily ever since.
> 
> This requirement has caused a lot of wreckage in the world and should
> be removed.

There is no UI requirement.  There is a no-auto-redirect requirement.

>>> The only counter rationale I've seen on this list is that the
>>> requirement is actually meaningless under a theory of
>>> "pre-confirmation."  If the requirement is meaningless, that means we
>>> should remove it as well.
>>> 
>>> Kindly remove the requirement.
>> 
>> I don't think we should remove the requirement entirely; but we should
>> explain the problem, and elaborate how clients that can't confirm with the
>> user at the time of the request can implement it.
> 
> Wire-level protocols shouldn't dictate user interface requirements.

It doesn't.  I'd really appreciate more thought and less tired mantra.

> This is a massive layering violation that is widely ignored by many
> popular user agents.  The user agents that don't ignore the
> requirement cause serious interoperability problems, to the extent of
> making the feature basically unusable by folks who care about their
> user experience.  Kindly remove it.

The user agents didn't implement same-origin policies either, until
enough security folks got on their case.  Kindly fix your holes.

....Roy

Received on Thursday, 19 August 2010 21:06:45 UTC