Subject: User confirmation and 307 redirects

From: Adam Barth <[email-masked]>
Date: Wed, 18 Aug 2010 14:27:03 -0700

http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-11#section-8.3.8 says

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

As has been pointed out by multiple folks on multiple occasions, this
requirement should be removed for the following reasons:

1) HTTP ought not to impose constraints on the user agent's user
interface.  This requirement is not appropriate for all user agents,
for example a GPS navigation unit in a car.
2) This requirement does not reflect reality.  A number of widely used
user agents disregard this requirement.
3) This requirement is actively harmful to interoperability.  Web
sites cannot reliably use 307 redirects because it triggers awful UI
mandated by this requirement in some user agents.

The only counter rationale I've seen on this list is that the
requirement is actually meaningless under a theory of
"pre-confirmation."  If the requirement is meaningless, that means we
should remove it as well.

Kindly remove the requirement.

Adam

---

From: Robert Sayre <[email-masked]>
Date: Wed, 18 Aug 2010 18:09:15 -0400

On Wed, Aug 18, 2010 at 5:27 PM, Adam Barth <[email-masked]> wrote:
> interface.

I agree here, in general. It's much better to clearly define the
meaning of the messages rather than impose behavior constraints on the
the UA or server. One exception would be where automated behavior
causes retransmissions, etc. But that's right in the requirements RFC,
and I take it everyone knows that.

-- 

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

---

From: Julian Reschke <[email-masked]>
Date: Thu, 19 Aug 2010 11:49:10 +0200

Hi Adam,

thanks for the reminder. This needs to be tracked.

>     this might change the conditions under which the request was issued.

Note: 301 and 302 have the same requirements.

> for example a GPS navigation unit in a car.

Question for clarification: what kind of unsafe methods would you expect 
that unit to make?

> user agents disregard this requirement.

That doesn't *necessarily* mean that the requirement is wrong.

> mandated by this requirement in some user agents.

That would be a problem, indeed. (Context: Opera follows the requirement 
for 307, but not for 302).

For this discussion, it would be interesting to see an example for a 
POST being redirected.

> Kindly remove the requirement.

I don't think we should remove the requirement entirely; but we should 
explain the problem, and elaborate how clients that can't confirm with 
the user at the time of the request can implement it.

Best regards, Julian

---

From: Yves Lafon <[email-masked]>
Date: Thu, 19 Aug 2010 05:54:15 -0400 (EDT)

> mandated by this requirement in some user agents.

Only for non-safe operations, and it was already the case for 301 in 2616. 
Also "harmful to interoperability" is an untestable claim.

> should remove it as well.

I don't see this requirement as an UI requirement, but more as a semantic 
one. The user has to be aware of what is going on in the case of a 
redirected non-safe method.
So maybe we need a rewording of the requirement to make it clear that it 
is not an UI one.

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

---

From: Julian Reschke <[email-masked]>
Date: Thu, 19 Aug 2010 12:16:58 +0200

On 19.08.2010 11:54, Yves Lafon wrote:
> ...
> Only for non-safe operations, and it was already the case for 301 in
> 2616. Also "harmful to interoperability" is an untestable claim.
> ...

Which reminds me that the much more serious interop problems for 307 
redirects on POST is that Safari is rewriting the message to GET. I know 
this problem has been reported to Apple over two years ago...

Best regards, Julian

---

From: "Anne van Kesteren" <[email-masked]>
Date: Thu, 19 Aug 2010 13:58:46 +0200

> this problem has been reported to Apple over two years ago...

If you do not want to show UI or inform the user of something most users  
cannot comprehend and you do not want to do something "dangerous" it seems  
somewhat okayish to issue a GET instead.

(I'm not at all in favor of what Opera implements currently for 307 by the  
way.)

-- 
Anne van Kesteren
http://annevankesteren.nl/

---

From: Julian Reschke <[email-masked]>
Date: Thu, 19 Aug 2010 14:09:20 +0200

On 19.08.2010 13:58, Anne van Kesteren wrote:
> On Thu, 19 Aug 2010 12:16:58 +0200, Julian Reschke
> <[email-masked]> wrote:
>> redirects on POST is that Safari is rewriting the message to GET. I
>> know this problem has been reported to Apple over two years ago...
>
> cannot comprehend and you do not want to do something "dangerous" it
> seems somewhat okayish to issue a GET instead.

Yes, but in that case 307 is the wrong status code; use 303 instead.

Best regards, Julian

---

From: "Anne van Kesteren" <[email-masked]>
Date: Thu, 19 Aug 2010 14:12:00 +0200

> Yes, but in that case 307 is the wrong status code; use 303 instead.

Except that the browser cannot control what status code the server gives.  
o_O

---

From: Julian Reschke <[email-masked]>
Date: Thu, 19 Aug 2010 14:17:53 +0200

On 19.08.2010 14:12, Anne van Kesteren wrote:
> On Thu, 19 Aug 2010 14:09:20 +0200, Julian Reschke
> Except that the browser cannot control what status code the server
> gives. o_O

Well, the server knows what's supposed to happen.

If the server wants you to do a POST to a new URI, and you don't want to 
do the POST, then doing a GET instead simply is a bug. Incorrect. Wrong. 
Bad.

Best regards, Julian

---

From: "Anne van Kesteren" <[email-masked]>
Date: Thu, 19 Aug 2010 14:20:36 +0200

> do the POST, then doing a GET instead simply is a bug. Incorrect. Wrong.  

It seems you are ignoring the concerns posted here. Not really sure how to  
continue discussing this issue then.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 19 Aug 2010 14:36:23 +0200

On 19.08.2010 14:20, Anne van Kesteren wrote:
> On Thu, 19 Aug 2010 14:17:53 +0200, Julian Reschke
>> If the server wants you to do a POST to a new URI, and you don't want
>> to do the POST, then doing a GET instead simply is a bug. Incorrect.
>> Wrong. Bad.
>
> It seems you are ignoring the concerns posted here. Not really sure how
> to continue discussing this issue then.

The concern Adam voiced was that using a 307 on an unsafe request has 
interop problems because some browsers (Opera) come up with a 
confirmation dialogue, while others do not.

To this I added that a more severe interop problem is that one browser 
rewrites the method to GET (Safari).

Could you please elaborate what the other concern is? It appears you 
argued that rewriting the method to GET actually is okay. I disagree; if 
the server expects a POST, sending a GET instead doesn't help anybody at 
all. If the server *wanted* to receive a GET request it would have said 
so using 303. Sending a GET instead will probably display something in 
the browser, but will not be what the server expected, and thus, in 
particular, have not the expected *effect*.

I totally agree that we have various problems with both the spec and the 
implementations of 3xx. But can we please stick to those things that 
belong into this category, instead of claiming that what Safari does 
(and what is a severe and long-known bug) suddenly is "okay-ish"?

Best regards, Julian

---

From: Maciej Stachowiak <[email-masked]>
Date: Thu, 19 Aug 2010 09:49:59 -0700

+1

I gave this feedback some time ago, and while there was some discussion, there wasn't a clear decision on how to proceed.

Julian mentions that this requirement also applies to 301 to 302, and I think it should be removed for those status codes as well. However, in those cases, it is more of a theoretical problem, since in practice browsers convert 301 and 302 redirects to GET. The draft acknowledges this in notes but does not make clear whether it is a conforming behavior.

Regards,
Maciej

---

From: Adam Barth <[email-masked]>
Date: Thu, 19 Aug 2010 10:29:01 -0700

> Question for clarification: what kind of unsafe methods would you expect

POST requests, e.g., to send traffic data to the server.

>From the charter:

[[
  * Remove or deprecate those features that are not widely implemented
  and also unduly affect interoperability
]]

This feature is widely not implemented and unduly affects interoperability.

> That would be a problem, indeed. (Context: Opera follows the requirement for
> 307, but not for 302).
>
> For this discussion, it would be interesting to see an example for a POST
> being redirected.

These examples are rare on the public Internet because of the lack of
interoperability and the ugliness of the UI requirement.  However,
when Chrome has a UI dialog, we received bug reports from folks about
intranet sites that popped up the dialog (because most of their users
where using IE, which omits the dialog).  I then removed the dialog,
and we've lived happily ever since.

This requirement has caused a lot of wreckage in the world and should
be removed.

> explain the problem, and elaborate how clients that can't confirm with the
> user at the time of the request can implement it.

Wire-level protocols shouldn't dictate user interface requirements.
This is a massive layering violation that is widely ignored by many
popular user agents.  The user agents that don't ignore the
requirement cause serious interoperability problems, to the extent of
making the feature basically unusable by folks who care about their
user experience.  Kindly remove it.

Adam

---

From: Maciej Stachowiak <[email-masked]>
Date: Thu, 19 Aug 2010 09:58:44 -0700

On Aug 19, 2010, at 9:47 AM, Julian Reschke wrote:

> On 19.08.2010 18:38, Mark Pauley wrote:
>> We know about the 307 issue, and I believe it has been addressed.  Essentially, any piece of code that can't put up UI can't auto-follow a 307.
> 
> I'm not going to say "yes" or "no" here :-)
> 
> Just clarifying: the Safari issue I was talking about is not about the missing confirmation, but about the method rewriting.

Safari 5 will properly preserve the method on a 307 redirect (and possibly earlier versions, I didn't check how long ago the fix went in). We had this bug for a while in previous versions, but no longer do.

We do not show any UI on a 307.

Regards,
Maciej

---

From: Julian Reschke <[email-masked]>
Date: Thu, 19 Aug 2010 18:55:40 +0200

On 19.08.2010 18:45, Maciej Stachowiak wrote:
> ...
> Safari did have this bug a while ago, but it has been fixed for some time. We have tests in our regression test suite which verify that 307 redirects preserve the original method and request body.
> ...

I just tried

   <http://www.mnot.net/javascript/xmlhttprequest/>

with Safari 5.0.1 on Win7, and it appears the problem is still there 
(maybe the code path is different for XMLHttpRequest?).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 19 Aug 2010 18:47:23 +0200

Just clarifying: the Safari issue I was talking about is not about the 
missing confirmation, but about the method rewriting.

Best regards, Julian

---

From: Mark Pauley <[email-masked]>
Date: Thu, 19 Aug 2010 09:38:27 -0700

_Mark

On Aug 19, 2010, at 5:36 AM, Julian Reschke wrote:

> The concern Adam voiced was that using a 307 on an unsafe request has interop problems because some browsers (Opera) come up with a confirmation dialogue, while others do not.
> 
> To this I added that a more severe interop problem is that one browser rewrites the method to GET (Safari).
> 
> Could you please elaborate what the other concern is? It appears you argued that rewriting the method to GET actually is okay. I disagree; if the server expects a POST, sending a GET instead doesn't help anybody at all. If the server *wanted* to receive a GET request it would have said so using 303. Sending a GET instead will probably display something in the browser, but will not be what the server expected, and thus, in particular, have not the expected *effect*.
> 
> I totally agree that we have various problems with both the spec and the implementations of 3xx. But can we please stick to those things that belong into this category, instead of claiming that what Safari does (and what is a severe and long-known bug) suddenly is "okay-ish"?
> 
> Best regards, Julian
>

---

From: Maciej Stachowiak <[email-masked]>
Date: Thu, 19 Aug 2010 10:13:11 -0700

On Aug 19, 2010, at 9:55 AM, Julian Reschke wrote:

> with Safari 5.0.1 on Win7, and it appears the problem is still there (maybe the code path is different for XMLHttpRequest?).

I don't know of a reason XHR would behave differently.

I tried one of our relevant tests myself and 307 redirects do preserve the method in our testing. I don't have a live copy that you can try but the following links show the sources to the test, and you can try it under your own Apache instance if you like:

http://trac.webkit.org/browser/trunk/LayoutTests/http/tests/loading/redirect-methods.html
http://trac.webkit.org/browser/trunk/LayoutTests/http/tests/loading/resources/redirect-methods-form.html
http://trac.webkit.org/browser/trunk/LayoutTests/http/tests/loading/resources/redirect-methods-result.php

I can try to investigate why mnot's test is giving different results. It would be helpful if I could see the source for the server-side parts of that test.

Regards,
Maciej

---

From: Maciej Stachowiak <[email-masked]>
Date: Thu, 19 Aug 2010 09:45:45 -0700

On Aug 19, 2010, at 3:16 AM, Julian Reschke wrote:

> Which reminds me that the much more serious interop problems for 307 redirects on POST is that Safari is rewriting the message to GET. I know this problem has been reported to Apple over two years ago...

Regards,
Maciej

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 19 Aug 2010 14:06:13 -0700

> This feature is widely not implemented and unduly affects interoperability.

It isn't a feature.  It is a security constraint.  The fact that some
browsers have security holes is well known.

> This requirement has caused a lot of wreckage in the world and should

There is no UI requirement.  There is a no-auto-redirect requirement.

> Wire-level protocols shouldn't dictate user interface requirements.

It doesn't.  I'd really appreciate more thought and less tired mantra.

> user experience.  Kindly remove it.

The user agents didn't implement same-origin policies either, until
enough security folks got on their case.  Kindly fix your holes.

....Roy

---

From: Adam Barth <[email-masked]>
Date: Thu, 19 Aug 2010 14:10:48 -0700

> browsers have security holes is well known.

It's completely ineffective as a security mechanism.  At best, all it
could do is result in blame-the-user security, which isn't security at
all.

Adam

---

From: Mark Pauley <[email-masked]>
Date: Thu, 19 Aug 2010 14:27:31 -0700

I agree, if a 3rd party can send you a redirect, they probably have your bytes too.  TLS is the only mechanism I can think of that can beat this threat and TLS makes the UI confirmation unnecessary, because we've already established that we trust the endpoint enough to send them our sensitive data.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 19 Aug 2010 23:32:32 +0200

> POST requests, e.g., to send traffic data to the server.

So, in this use case, why does the redirect happen in the first place? 
Server handling the traffic data moved?

Best regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 19 Aug 2010 14:37:28 -0700

> could do is result in blame-the-user security, which isn't security at

Please think about it for a while before you try to convince me that a
DELETE on any website on the planet should be able to result in an automatic
DELETE being redirected to any other website on the planet, or your
local intranet.  Likewise for PUT, POST, etc.

There is no compelling need for auto-redirect for an unsafe method.
If you can't figure out a safe way that your "user" (an entity which
varies substantially based on the type of HTTP client being used)
can approve of the redirect, then the safe choice is to not redirect
the request.  Your concerns about the ugliness of such a dialog are
not relevant to the requirement as written in the spec, and it simply
wouldn't matter if every single browser implemented it wrong:
browsers make up only a small percentage of HTTP client vendors.

....Roy

---

From: Adam Barth <[email-masked]>
Date: Thu, 19 Aug 2010 14:39:58 -0700

> Server handling the traffic data moved?

There are any number of reasons the traffic server might return a
redirect.  For example, suppose the main traffic server is overloaded
and wants to offload the processing of this request to another server
(say in a different datacenter) temporarily.

Even though the in-car navigation unit has a user interface, it's
definitely wrong to make the user confirm this redirect.  The user is
busy driving!

Adam

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 19 Aug 2010 15:11:08 -0700

> I agree, if a 3rd party can send you a redirect, they probably have your bytes too.  TLS is the only mechanism I can think of that can beat this threat and TLS makes the UI confirmation unnecessary…

Revealing data is not the issue.  It is relatively easy to construct a
request that has one meaning on one site (e.g., "unsubscribe me from
your spam list") and an entirely different meaning when redirected
to a different site (e.g., "send this spam message to all of my
facebook friends").  Both sites can be using TLS.  It is a similar but
slightly different problem as CSRF, with the main difference being
that the redirected request is caused by HTTP (as opposed to phishing
or javascript).

Likewise, you don't want write or delete requests made to your game's
webdav file share to be able to make changes to your Apple network
file server.  There are hundreds of other non-browser applications
of HTTP that would be adversely impacted by such a change.

The fact that there are different ways to trigger the same vulnerability
in HTML with javascript and XHR POST is a separate issue that *this* WG
has no ability to fix.  The IETF does not deliberately add new security
holes to a standards-track protocol just because some developers are
irresponsible.

....Roy

---

From: Adam Barth <[email-masked]>
Date: Thu, 19 Aug 2010 15:20:12 -0700

> holes to a standards-track protocol just because some developers are

If you think that 307 redirects are a security vulnerability, then
should should remove them from the protocol.  Trying to atone for the
security sins of the protocol by punting security to the user is
security theater.

Adam

---

From: Robert Sayre <[email-masked]>
Date: Thu, 19 Aug 2010 18:21:05 -0400

On Thu, Aug 19, 2010 at 5:37 PM, Roy T. Fielding <[email-masked]> wrote:
> can approve of the redirect

The term "user" has a very vague definition. That's OK. But that
variance makes RFC 2119 requirements that hinge on consulting the user
very close to meaningless.

-- 

Robert Sayre

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 19 Aug 2010 15:37:18 -0700

> security sins of the protocol by punting security to the user is

Using the Internet is a security vulnerability, yet there are sufficient
trade-offs to justify it.   The same goes for redirecting an unsafe
method if and only if the redirection has been preconfigured or
acknowledged by the user.  How that is arranged is not defined by
the protocol -- it is left up to the user agent developer to decide
on their own user interface *if* they want to autoredirect an unsafe
method.

I don't care if you think all users are idiots.  They are responsible
for their own use of the Internet.  The user agent is responsible for
showing/configuring what decisions need to be made by the user.  HTTP
is only responsible for ensuring that the protocol expresses what the
user has decided, and to do that correctly it has to constrain the
automatic redirection of unsafe methods unless or until that decision
is made by the user.

....Roy

---

From: Adam Barth <[email-masked]>
Date: Thu, 19 Aug 2010 15:44:48 -0700

> on their own user interface *if* they want to autoredirect an unsafe

The draft says:

[[
  Otherwise, the user agent MUST NOT automatically
  redirect the request unless it can be confirmed by the user
]]

If the user agent developer can choose whether or not to autoredirect
an unsafe method, in what sense is this requirement a MUST NOT?

Adam

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 19 Aug 2010 16:21:23 -0700

> an unsafe method, in what sense is this requirement a MUST NOT?

The user interface for obtaining confirmation is designed by the
user agent developer.  The user agent developer can choose to never
automatically redirect, provide some form of whitelist or zone
functionality that preapproves such an automated redirect, or
obtain a confirmation directly from the user upon receipt of
the redirect -- any one of those satisfies the HTTP requirement.

And, yes, an automobile navigation system that stupidly depends
on redirects (as opposed to DNS or IP redirection that doesn't
require the body of the message to be sent twice) can easily be
preconfigured to allow automatic redirects to known safe sites.
The "user" is the person that causes the request to be initiated,
which in your scenario is the navigation system's programmer,
not the driver.

....Roy

---

From: Dirk Pranke <[email-masked]>
Date: Thu, 19 Aug 2010 16:39:40 -0700

> the redirect -- any one of those satisfies the HTTP requirement.

If the user agent developer can choose to whitelist some redirects,
doesn't that directly contradict the text?

Also, suggesting that the "user" is the designer of the UI (or the
programmer), and not the viewer or the end-user, would seem to
contradict common usage in our specs.

-- Dirk

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 19 Aug 2010 17:23:22 -0700

> doesn't that directly contradict the text?

No.  Whitelists are just a prearranged form of confirmation.
In any case, we already discussed changing the text to be more
clear, like the paragraph above; it should be somewhere
in the list of editorial issues.

> contradict common usage in our specs.

Then your specs assume that a viewer is driving the application of
computing for which the specification exists.  HTTP doesn't.

If I install a maintenance spider and it proceeds to crawl
the Internet while I am off sleeping, then I am the user because
I configured the crawl, not because I am viewing it in action.

If I turn on a navigation system and it proceeds to perform a
bunch of hidden requests in the background that I had no part
in selecting, then I am most definitely not the user from the
perspective of those requests.  If, however, it provides some
UI for making such a decision, such as "Send traffic updates to X",
then I am the user and the system is equally capable of
explaining X in such a way that it is a group of potential sites
(e.g., "send traffic updates to Google") rather than something
else, like "send my location information to anyone in the world".

....Roy

---

From: Dirk Pranke <[email-masked]>
Date: Thu, 19 Aug 2010 17:58:10 -0700

> in the list of editorial issues.

Whitelists are a prearranged form of confirmation, but if the user
didn't create
the whitelist (or at least authorize it), then it seems to me to be not
in the spirit of the requirement (or at least it also blurs the
definition of user as per below).

> computing for which the specification exists.  HTTP doesn't.

No, I'm suggesting that "user" is usually understood to mean "end
user" aka "a human being" (where user agent is the intermediary
software program). I gather you are suggesting that "code running at
the next layer up in the stack" is also a user? It's not clear to me
how one would then draw the line between "user" and "user agent" in
the spec, so perhaps that should also be clarified as part of the
editorial tasks.

> I configured the crawl, not because I am viewing it in action.

Sure, but you *as a user* explicitly initiated the action and
presumably are quite familiar with what the behavior of the spider
would be when you configured it (assuming you explicitly configured
--follow-307s or something). If you didn't explicitly configure that
choice, I would interpret the spec as saying that the spider should
stop to confirm the redirect with you, or be forced to redefine "user"
as per above.

> else, like "send my location information to anyone in the world".

In these paragraphs it seems clear to me that you are referring to the
"user" as if the term refers to a human being, so it still seems to me
to that. if you're not contradicting yourself, you're at least not
providing good examples for your argument. Perhaps you are suggesting
that the user is implicitly agreeing to the redirects by installing
the software at all? That seems like a reach.

I apologize if this sounds confrontational; I'm just trying to
understand your position. Also, I am not clear on what you think would
be the acceptably clearer text that "we already discussed"; was that
in an earlier thread? It didn't seem like you agreed to changing the
text at all in this particular thread.

-- Dirk

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 20 Aug 2010 11:15:09 +1000

Thanks for reminding us of this, Adam. When you brought it up in Maastricht, we created:
  http://trac.tools.ietf.org/wg/httpbis/trac/ticket/238

Cheers,

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

---

From: Adam Barth <[email-masked]>
Date: Thu, 19 Aug 2010 18:18:21 -0700

Thanks Mark.  I looked in the issue tracker before sending my mail,
but I didn't find the ticket (I think because I was looking for the
keyword 307).

Adam

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 20 Aug 2010 11:28:11 +1000

So, keeping this discussion in mind, some might interpret all of the following as conforming to the requirement:

* Any software that uses Curl with the --location option (or the corresponding libcurl arguments)

* A browser which allows the user to configure a 'redirect whitelist'

* A browser which follows all redirects (regardless of method), but has a 'redirect blacklist' for exceptions

* A browser that has a 'automatically follow all redirects to the same domain' preference box ticked

* A browser whose documentation says that it will automatically follow all redirects, regardless of method

Obviously, some of these are more useful for guarding against misuse than others.

I think at a minimum we need:

  1) An explanation of the risks of following redirects for non-GET methods
  2) Expansion on what "can be confirmed by the user" means

Also, it seems to me that it'd be useful to figure out what 'not automatically redirecting' means. The browsers, in their own way, have conformed to this requirement partially by converting unsafe requests into safe ones -- by changing the method to GET.

Cheers,

---

From: Julian Reschke <[email-masked]>
Date: Fri, 20 Aug 2010 11:18:57 +0200

Hi,

FYI: I re-ran the test and sent an HTTP trace offlist.

Anne: regarding XHR -- a silent rewrite of the method is invisible to 
the caller and thus a bug. On the other hand, silently following the 
redirect for an unsafe method is still a problem, no matter how we 
phrase it in httpbis. The safest approach for XHR would be to allow 
implementations not to follow the redirect, and let the caller handle it 
instead.

Best regards, Julian

PS: apologies for claiming that the bug was reported two years ago; I 
mixed up IETF meetings. In fact it was reported *one* year ago.

---

From: Maciej Stachowiak <[email-masked]>
Date: Fri, 20 Aug 2010 03:42:51 -0700

> local intranet.  Likewise for PUT, POST, etc.

1) For PUT and POST, just visiting any website on the planet with a mainstream browser in its default configuration can result in an automatic PUT or POST to any website on the planet. That's somewhat unfortunate, but it is a reality that at this point can't be changed. Trying to prevent this (or, worse yet, throwing up a confirmation dialog) only in the case where a redirect is involved is silly.

In the case of DELETE, this can't be done with mainstream browsers, since the only ways available to produce a DELETE request do not transparently

2) I note also that the requirement as stated applies even to the same-site case. In what way is a security mechanism then? 

3) Most browsers in their default configurations will not show the user where a form submission will go or what HTTP method it will use before the user hits the submit button. The form could have submitted a POST to a "bad" place in the first place. Why require user confirmation only in the case where an HTTP redirect happened, since the user did not know where his or her form was going in the first place?

> the request.

Generally, "always fail" is a stronger security mechanism than "prompt the user". However, in this case, it's still ineffective in the context of a browser, since there are so many other ways to maliciously POST to a URI that wasn't chosen by the user. You don't even have to use script to do it.

>  Your concerns about the ugliness of such a dialog are

Are there categories of HTTP clients that generally do follow this requirement, other than via an assumption that their "user" is someone other than the end-user, or that their end-user has given blanket confirmation?

Regards,
Maciej

---

From: Maciej Stachowiak <[email-masked]>
Date: Fri, 20 Aug 2010 03:48:24 -0700

> FYI: I re-ran the test and sent an HTTP trace offlist.

For those playing along at home, I investigated and the remaining bug in Safari seems to be specific to synchronous XMLHttpRequest (and not ordinary async XHR, or any other resource load).

Regards,
Maciej

---

From: Adam Barth <[email-masked]>
Date: Fri, 20 Aug 2010 10:41:40 -0700

> 1) For PUT and POST, just visiting any website on the planet with a mainstream browser in its default configuration can result in an automatic PUT or POST to any website on the planet. That's somew…

I believe that only works for POST.  HTML5 introduces the ability to
send PUT and DELETE via forms, but only back to the same-origin.  It
also explicitly blocks attempts to redirect these methods off-origin.

Roy, of course, would say that there are other HTTP user agents than
browsers.  :)

The way that I think makes sense to resolve this issue is as follows:

1) Remove the contrary-to-reality MUST NOT from the spec.
2) Add text (either inline in the definition of the redirects or in
the security considerations section) that explains the security
consequences of blindly following redirects with unsafe methods.

User agents can make up their own mind how they should mitigate those
threats.  Different user agents will make different decisions based on
a slew of factors, including what other functionality they expose
(e.g., that makes mitigating this threat pointless) or their usage
environment (e.g, not wanting to distract their users while driving
their cars).

Adam

---

From: "Anne van Kesteren" <[email-masked]>
Date: Tue, 24 Aug 2010 17:03:39 +0200

> implementations not to follow the redirect, and let the caller handle it  

http://tools.ietf.org/html/rfc2616#section-9.1.1 does not really make a  
requirement on UI of user agents. Why is it so much stronger for  
redirects? It makes no sense. Especially if we at some point give script  
authors control over handling redirects so they can implement following  
redirects themselves.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 27 Aug 2010 13:33:54 +0200

On 24.08.2010 17:03, Anne van Kesteren wrote:
> On Fri, 20 Aug 2010 11:18:57 +0200, Julian Reschke
>> implementations not to follow the redirect, and let the caller handle
>> it instead.
>

I really have no idea why the requirements have been phrased the way 
they are. I do agree that more consistency is needed here.

Best regards, Julian