Subject: Re: User interface requirements for redirecting to unsafe methods

From: Maciej Stachowiak <[email-masked]>
Date: Mon, 22 Oct 2012 23:42:49 -0700

I read recently that httpbis believes it has addressed the feedback of all those who brought it to their satisfaction, and that the WG is in WGLC so such feedback should be re-raised if not. 

The following points were not addressed to my satisfaction. While some individuals replied, so far as I can tell, the WG itself has never officially tracked this feedback nor has it given an official response.

You can find the post I'm replying to in the archives here: <http://lists.w3.org/Archives/Public/ietf-http-wg/2010JanMar/0170.html>
As far as I can tell, the end of the discussion on this was the following post from me: <http://lists.w3.org/Archives/Public/ietf-http-wg/2010JanMar/0177.html>.

I would like to have this feedback addressed by the httpbis wg.

Regards,
Maciej

On Feb 12, 2010, at 2:30 AM, Maciej Stachowiak <[email-masked]> 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."
> 
> <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: Tue, 23 Oct 2012 09:00:43 +0200

On 2012-10-23 08:42, Maciej Stachowiak wrote:
> ...

Maciej,

the text you complained about back then has been rewritten a few months 
ago. Please check the WGLC draft.

With respect to tracking: I think this is issue 
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/238>, see also 
<http://lists.w3.org/Archives/Public/ietf-http-wg/2012JanMar/0928.html>.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 23 Oct 2012 18:12:15 +1100

On 23/10/2012, at 6:00 PM, Julian Reschke <[email-masked]> wrote:
> 
> the text you complained about back then has been rewritten a few months ago. Please check the WGLC draft.
> 
> With respect to tracking: I think this is issue <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/238>, see also <http://lists.w3.org/Archives/Public/ietf-http-wg/2012JanMar/0928.html>.

Yes. 

I do see, however, that we have this language at the top of <http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-21#section-7.4>:

> If the required action involves a subsequent HTTP request, it 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 known to be "safe", as
>    defined in Section 5.2.1.

MAY... if and only if is a badly constructed requirement, and it also goes against the resolution of #238. I'll enter a WGLC issue to correct that.

Thanks,

--
Mark Nottingham   http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Tue, 23 Oct 2012 09:17:18 +0200

> MAY... if and only if is a badly constructed requirement, and it also goes against the resolution of #238. I'll enter a WGLC issue to correct that.

Indeed; when we resolved #238 we didn't fix all places where this was 
mentioned.

Best regards, Julian

---

From: Maciej Stachowiak <[email-masked]>
Date: Tue, 23 Oct 2012 01:56:48 -0700

On Oct 23, 2012, at 12:17 AM, Julian Reschke <[email-masked]> wrote:

> Indeed; when we resolved #238 we didn't fix all places where this was mentioned.

I only checked the first reference, which was apparently unfixed. I have now double-checked the others and they do seem to address the issue.

Thanks to Mark for offering to raise the overlooked spot as a WGLC issue.

As a matter of process, I wish I could have been notified in some more active way about the resolution when the ticket was resolved. Since it was resolved several years after I raised the issue, I was no longer monitoring the WG closely enough to notice. Had I been aware of the resolution, I likely would have spotted the error (i.e. that one of four mentions of confirmation was not addressed).

Cheers,
Maciej

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 23 Oct 2012 21:16:44 +1100

> As a matter of process, I wish I could have been notified in some more active way about the resolution when the ticket was resolved. Since it was resolved several years after I raised the issue, I…

That's not our process. We use the issue tracker as a convenience (as we do the diffs, the announcements, the change logs, etc.), but ultimately if you care about a particular bit of the text, you need to track it. Hence, the Last Calls (whereupon you *did* spot the error).

Regards,

---

From: Barry Leiba <[email-masked]>
Date: Tue, 23 Oct 2012 10:51:35 -0400

>
> The following points were not addressed to my satisfaction. While some
> individuals replied, so far as I can tell, the WG itself has never
> officially tracked this feedback nor has it given an official response.
>
> You can find the post I'm replying to in the archives here: <
> http://lists.w3.org/Archives/Public/ietf-http-wg/2010JanMar/0170.html>
> As far as I can tell, the end of the discussion on this was the following
> post from me: <
> http://lists.w3.org/Archives/Public/ietf-http-wg/2010JanMar/0177.html>.

I agree with Maciej that (1) he has raised a valid set of issues and (2)
they have not been adequately addressed.

In fact, I also agree with his assessment, and think the "must" and "must
not" statements should be changed to "should" and "should not", though that
is separate from my concern that his issues have not been adequately
addressed.  I'd at least like to hear someone explain *why* the "must ->
should" change would be bad or wrong, and see support for that explanation.

I can also make a pretty good guess that Pete or I might raise just this
sort of thing in IESG Evaluation.

Barry, responsible AD

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

---

From: Barry Leiba <[email-masked]>
Date: Tue, 23 Oct 2012 10:53:53 -0400

> they have not been adequately addressed.

Ignore this; I see that it's being dealt with in another thread.  's what
happens when discussions move and I'm replying from a limited client while
on the road.  Never mind.

Barry

---

From: Julian Reschke <[email-masked]>
Date: Tue, 23 Oct 2012 17:12:08 +0200

On 2012-10-23 16:51, Barry Leiba wrote:
>     The following points were not addressed to my satisfaction. While
>     some individuals replied, so far as I can tell, the WG itself has
>     never officially tracked this feedback nor has it given an official
>     response.
>
>     You can find the post I'm replying to in the archives here:
>     <http://lists.w3.org/Archives/Public/ietf-http-wg/2010JanMar/0170.html>
>     As far as I can tell, the end of the discussion on this was the
>     following post from me:
>     <http://lists.w3.org/Archives/Public/ietf-http-wg/2010JanMar/0177.html>.
>
>
> In fact, I also agree with his assessment, and think the "must" and
> "must not" statements should be changed to "should" and "should not",
> though that is separate from my concern that his issues have not been
> adequately addressed.  I'd at least like to hear someone explain *why*
> the "must -> should" change would be bad or wrong, and see support for
> that explanation.
> ...

The WG already decided to change the requirements to simple prose that 
just explains the issue. That being said, I'm not sure how changing a 
MUST (which isn't in the spec anyway anymore) to a SHOULD would actually 
help addressing Maciej's concern.

Best regards,

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 24 Oct 2012 12:39:31 +1100

Now <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/388>. Is editorial, since the decision was already made in #238.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 24 Oct 2012 13:24:37 +0200

> Now <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/388>. Is editorial, since the decision was already made in #238.

I believe we can just drop that sentence, as there's another paragraph 
later on that deals with the issue. With that change, the introduction 
would read:

7.4.  Redirection 3xx

    This class of status code indicates that further action needs to be
    taken by the user agent in order to fulfill the request.

    There are several types of redirects:

    1.  Redirects of the request to another URI, either temporarily or
        permanently.  The new URI is specified in the Location header
        field.  In this specification, the status codes 301 (Moved
        Permanently), 302 (Found), and 307 (Temporary Redirect) fall
        under this category.

    2.  Redirection to a new location that represents an indirect
        response to the request, such as the result of a POST operation
        to be retrieved with a subsequent GET request.  This is status
        code 303 (See Other).

    3.  Redirection offering a choice of matching resources for use by
        reactive content negotiation (Section 3.4.2).  This is status
        code 300 (Multiple Choices).

    4.  Other kinds of redirection, such as to a cached result (status
        code 304 (Not Modified), see Section 4.1 of [Part4]).

       Note: In HTTP/1.0, only the status codes 301 (Moved Permanently)
       and 302 (Found) were defined for the first type of redirect, and
       the second type did not exist at all ([RFC1945], Section 9.3).
       However it turned out that web forms using POST expected redirects
       to change the operation for the subsequent request to retrieval
       (GET).  To address this use case, HTTP/1.1 introduced the second
       type of redirect with the status code 303 (See Other) ([RFC2068],
       Section 10.3.4).  As user agents did not change their behavior to
       maintain backwards compatibility, the first revision of HTTP/1.1
       added yet another status code, 307 (Temporary Redirect), for which
       the backwards compatibility problems did not apply ([RFC2616],
       Section 10.3.8).  Over 10 years later, most user agents still do
       method rewriting for status codes 301 and 302, therefore this
       specification makes that behavior conformant in case the original
       request was POST.

    A Location header field on a 3xx response indicates that a client MAY
    automatically redirect to the URI provided; see Section 8.1.2.

    Note that for methods not known to be "safe", as defined in
    Section 5.2.1, automatic redirection needs to done with care, since
    the redirect might change the conditions under which the request was
    issued.

    Clients SHOULD detect and intervene in cyclical redirections (i.e.,
    "infinite" redirection loops).

       Note: An earlier version of this specification recommended a
       maximum of five redirections ([RFC2068], Section 10.3).  Content
       developers need to be aware that some clients might implement such
       a fixed limitation.

(see 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/388/388.diff>)

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 24 Oct 2012 23:02:41 +1100

+1

On 24/10/2012, at 10:24 PM, Julian Reschke <[email-masked]> wrote:

> I believe we can just drop that sentence, as there's another paragraph later on that deals with the issue. With that change, the introduction would read:
> 
> 7.4.  Redirection 3xx
> 
> (see <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/388/388.diff>)
> 
> Best regards, Julian
>

---

From: Julian Reschke <[email-masked]>
Date: Wed, 24 Oct 2012 14:35:36 +0200

-> <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1950>