Re: User interface requirements for redirecting to unsafe methods

Maciej Stachowiak wrote:
> 
> RFC2616 has some MUST-level user interface requirements relating 
> redirecting to unsafe methods:
> 
> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-latest.html#status.3xx> 
> 
> "The action required may be carried out by the user agent without 
> interaction with the user if and only if the method used in the second 
> request is GET or HEAD."

That's a bug. It should talk about safe methods. Re-opening a very old 
ticket: <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/10#comment:5>.

> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-latest.html#status.301> 
> 
> "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."
> 
> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-latest.html#status.302> 
> 
> "If the 302 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."
> 
> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-latest.html#status.307> 
> 
> "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."
> 
> 
> I suggest that these requirements should be removed (or at least changed 
> to SHOULD- or MAY-level) for the following reasons:
> 
> 1) It is inappropriate to dictate user interface requirements. A 
> protocol spec should limit itself to the syntax, semantics and 
> processing requirements of protocol elements. It should not attempt to 
> dictate the user interface of tools using the protocol.

That's debatable.

> 2) There are no requirements for user agents to confirm an initial 
> request made with a non-idempotent method with the user, to make such 
> requests only in response to explicit user actions, or to let the user 
> know that when they take an action that will request a new resource, 
> that it is being made with an unsafe method, or what host the request is 
> being sent to. Thus, the requirement to get user confirmation only on 
> redirects to an unsafe method is not effective in preventing such 
> requests from being made without the user's knowledge.

See 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-latest.html#rfc.section.7.1.1>:

"...Implementors should be aware that the software represents the user 
in their interactions over the Internet, and should be careful to allow 
the user to be aware of any actions they might take which may have an 
unexpected significance to themselves or others.

In particular, the convention has been established that the GET, HEAD, 
OPTIONS, and TRACE methods SHOULD NOT have the significance of taking an 
action other than retrieval. These methods ought to be considered 
"safe". This allows user agents to represent other methods, such as 
POST, PUT and DELETE, in a special way, so that the user is made aware 
of the fact that a possibly unsafe action is being requested...."

> ...
> 5) RFC2119 says "Imperatives of the type defined in this memo must be 
> used with care and sparingly.  In particular, they MUST only be used 
> where it is actually required for interoperation or to limit behavior 
> which has potential for causing harm." In this case, there is no 
> interoperability need for these requirements. And furthermore, per point 
> 2, the requirements do not actually limit any behavior.
> ...

See above.

> 6) The requirements cannot be met by a user agent that normally operates 
> without direct user interaction.

Confirming with the user doesn't not necessarily mean that this needs to 
happen in time the 3xx is encountered. That being said, I agree that it 
would be good add more guidance here.

Best regards, Julian

Received on Friday, 12 February 2010 10:58:24 UTC