Re: User interface requirements for redirecting to unsafe methods

On Feb 12, 2010, at 3:11 AM, Maciej Stachowiak wrote:
> On Feb 12, 2010, at 2:57 AM, Julian Reschke wrote:
> 
>> 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.
> 
> Do you have a counter-argument? What possible justification can there be for a protocol specification to place requirements on application UI?

It doesn't place requirements on the UI.  It places a constraint on
automated continuation of a multi-request sequence (the redirect protocol).

>>> 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...."
> 
> I don't see a normative requirement on user agents here. If the MUST-level requirements for redirects were replaced with similar non-normative suggestions, then that would be fine by me.

The normative requirement here is actually in HTML, not HTTP.

>>> ...
>>> 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.
> 
> Likewise. There's no normative requirement for user agents to do anything in particular to inform the user or seek user confirmation to make an unsafe request in the first place.

Why would there be?

>>> 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.
> 
> Removing the requirements in question, or making them SHOULD- or MAY-level, would address this. I should probably also add:
> 
> 7) The requirements do not make sense for client software that uses HTTP networking as part of its implementation, but this is largely hidden from the user. For example, let's say a program uses a SOAP API to implement part of an application feature that is not obviously Web- or network-related. Prompting the user about a redirect in such a case would be nonsensical, since the user is not even aware that he or she is using an HTTP user agent.

It doesn't require that the user be prompted.  It requires that clients
not include a rather obvious security hole or at least be specifically
configured by the user for that purpose (prior confirmation).

....Roy

Received on Sunday, 14 February 2010 22:06:57 UTC