Re: User interface requirements for redirecting to unsafe methods

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


> On Feb 12, 2010, at 2:30 AM, Maciej Stachowiak <mjs@apple.com> 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 requireme