Re: User confirmation and 307 redirects

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.

>> 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.

>> 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.
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.

Adam

Received on Thursday, 19 August 2010 17:55:53 UTC