User interface requirements for redirecting to unsafe methods

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

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

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.

3) In addition to there being no limit on making an initial unsafe  
request (such as a POST) without the user's knowledge by the language  
of the spec, the most popular browsers all will in fact allow such  
requests to be made with no knowing user interaction whatsoever. There  
are many ways to do it with scripting, here is a test case that shows  
it is possible even without scripting: <http://damowmow.com/playground/demos/http/002/ 
 >.

4) The statements claim that following a redirect to an unsafe method  
"might change the conditions under which the request was issued", but  
in fact it will not materially change the conditions compared to  
making a request to the server that is the target of the redirect in  
the first place. The only change in the resulting request will be the  
Referer header.

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.

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


Regards,
Maciej

Received on Friday, 12 February 2010 10:30:52 UTC