W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2010

Re: User confirmation and 307 redirects

From: Roy T. Fielding <fielding@gbiv.com>
Date: Thu, 19 Aug 2010 14:06:13 -0700
Cc: Julian Reschke <julian.reschke@gmx.de>, httpbis <ietf-http-wg@w3.org>, Maciej Stachowiak <mjs@apple.com>
Message-Id: <22ED9A66-431A-4F38-848C-A4087B9063D3@gbiv.com>
To: Adam Barth <ietf@adambarth.com>
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.

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

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:22 UTC