Re: User interface requirements for redirecting to unsafe methods

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?

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

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

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

Regards,
Maciej

Received on Friday, 12 February 2010 11:12:22 UTC