Re: User confirmation and 307 redirects

Hi Adam,

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?

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

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

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

Best regards, Julian

Received on Thursday, 19 August 2010 09:49:54 UTC