Subject: User interface requirements for redirecting to unsafe methods

From: Maciej Stachowiak <[email-masked]>
Date: Fri, 12 Feb 2010 02:30:18 -0800

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

---

From: Julian Reschke <[email-masked]>
Date: Fri, 12 Feb 2010 11:57:40 +0100

Maciej Stachowiak wrote:
> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-latest.html#status.3xx> 
> 

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

That's debatable.

> 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 

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

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

---

From: Maciej Stachowiak <[email-masked]>
Date: Fri, 12 Feb 2010 03:11:48 -0800

On Feb 12, 2010, at 2:57 AM, Julian Reschke wrote:

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

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

> 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

---

From: Julian Reschke <[email-masked]>
Date: Fri, 12 Feb 2010 12:11:51 +0100

> ticket: <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/10#comment:5>.

Fixed with <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/759> -- 
the introduction now says:

"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 is known to be "safe", as defined in Section 7.1.1."

Best regards, Julian

---

From: Adam Barth <[email-masked]>
Date: Fri, 12 Feb 2010 08:02:48 -0800

On Fri, Feb 12, 2010 at 3:11 AM, Julian Reschke <[email-masked]> wrote:
> Fixed with <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/759> -- the
> introduction now says:
>

I think you have "is" written twice there.

Adam

---

From: Adam Barth <[email-masked]>
Date: Sun, 14 Feb 2010 10:08:48 -0800

I agree that it doesn't make sense for a wire-level protocol to impose
MUST requirements on the user interface of user agents.

On Fri, Feb 12, 2010 at 3:11 AM, Maciej Stachowiak <[email-masked]> wrote:
> 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.

To give a concrete example here, imagine a in-dash navigation unit in
a car that uses HTTP to interact with a real-time traffic service.  If
the navigation unit receives a 307 redirect to a POST request from the
traffic service, does it really make sense to prompt the user?
Prompting the user might be dangerous because it might distract the
driver and cause him or her to crash the car.

Adam

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sun, 14 Feb 2010 14:06:24 -0800

On Feb 12, 2010, at 3:11 AM, 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

---

From: Maciej Stachowiak <[email-masked]>
Date: Sun, 14 Feb 2010 15:02:02 -0800

On Feb 14, 2010, at 2:06 PM, Roy T. Fielding wrote:

>>>> > "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."
>>>
>>>> then the request may be automatically redirected by the user  
>>>> agent without confirmation. Otherwise, the user agent must not  
>>>> then the request may be automatically redirected by the user  
>>>> agent without confirmation. Otherwise, the user agent must not  
>>>> then the request may be automatically redirected by the user  
>>>> agent without confirmation. Otherwise, the user agent must not  
>>>> 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?
>

"Confirmed by the user" seems to be a user interface requirement. The  
phrase "interaction with the user" also seems to signal a UI  
requirement. Neither the contents nor the semantics of the protocol  
message are affected by whether it was "confirmed by the user" or  
whether there was "interaction with the user".

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

I looked in both HTML4.01 (the current REC) and HTML5 (the current  
draft) and was unable to find a relevant normative requirement. As far  
as I can tell, there is no requirement on form submission to let the  
user know whether it will use a safe or unsafe method, to tell the  
user the URI that is being requested, to make requests using unsafe  
methods only as a result of user interaction, or to confirm requests  
using unsafe methods with the user. Or at least, I couldn't find it.

>
>>>> ...
>>>> 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.
>>
>> anything in particular to inform the user or seek user confirmation  
>> to make an unsafe request in the first place.
>
> Why would there be?

I can't think of a good reason for there to be such a requirement. But  
I also can't think of a good reason for the above listed requirements  
on redirects.

>> Removing the requirements in question, or making them SHOULD- or  
>> MAY-level, would address this. I should probably also add:
>>
>> 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.
>

On the face of it, this conformances requirement appears to require  
interaction with the user: "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." If it's not  
intended that interaction with the user is required, then certainly  
the wording could be clarified.

And this requirement appears to require that the user can confirm that  
specific request: "Otherwise, the user agent must not automatically  
redirect the request unless it can be confirmed by the user." By my  
reading, the referent of "it" is "the request". If that's not intended  
to require individual confirmation of each such redirect request, then  
once again, clearer wording would be helpful.

Also, could you please explain the security hole that would be created  
by not having the user confirm the request? It is not obvious to me. I  
would have expected that whatever security risk is presented by  
following a redirect of a POST is presented to the same degree by  
simply issuing a POST in the first place.

Regards,
Maciej