Subject: Protocols/APIs and redirects

From: "Anne van Kesteren" <[email-masked]>
Date: Tue, 06 Dec 2011 12:14:24 +0100

When we design APIs (XMLHttpRequest) and protocols (CORS) that support  
transparent redirects (redirects automatically followed by the API) what  
exactly should count as a redirect as far as they are concerned?  
Everything in the 3xx range that contains a Location header?

E.g. for some part of CORS  
http://dvcs.w3.org/hg/cors/raw-file/tip/Overview.html#actual-request we  
explicitly fail if the response code is 301, 302, 303, or 307, because we  
want the ability to support transparent redirects going forward. Should we  
also fail if the response code is 310?

Should  
http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#same-origin-request-event-rules  
follow redirects for status codes other than 301, 302, 303, and 307?  
Should it instead treat anything else as a network error so we can more  
easily extend it in the future? If we do not treat it as a network error  
the developer would just get back a response with a status code of 310 and  
the Location header and going forward we could never treat it as any of  
the "blessed redirects" anymore.

Aside: What happened to  
http://lists.w3.org/Archives/Public/ietf-http-wg/2011JulSep/0014.html ? I  
could not find the issue.

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

---

From: "Anne van Kesteren" <[email-masked]>
Date: Tue, 06 Dec 2011 12:22:32 +0100

On Tue, 06 Dec 2011 12:14:24 +0100, Anne van Kesteren <[email-masked]>  
wrote:
> explicitly fail if the response code is 301, 302, 303, or 307, because  
> we want the ability to support transparent redirects going forward.  
> Should we also fail if the response code is 310?
>
> Should  
> the developer would just get back a response with a status code of 310  
> and the Location header and going forward we could never treat it as any  
> of the "blessed redirects" anymore.

It seems this question is related to  
http://trac.tools.ietf.org/wg/httpbis/trac/ticket/325

> Aside: What happened to  
> http://lists.w3.org/Archives/Public/ietf-http-wg/2011JulSep/0014.html ?  
> I could not find the issue.

I could not find this issue in your database or in the mailing list  
archives since mnot said he would raise it. It was more or less by chance  
that I happened to look at it again because I vaguely recalled having  
raised a redirect issue earlier. I guess I did not use "NEW ISSUE" but  
then I did not know whether it was an issue when I started the thread. Can  
someone please fix this now?

---

From: Julian Reschke <[email-masked]>
Date: Tue, 06 Dec 2011 12:49:51 +0100

> Everything in the 3xx range that contains a Location header?

As you noticed, that's related to 
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/325>.

In general, any layer that automatically follows redirects will always 
be problematic, because it may depend on the application whether 
following the redirect or not is desirable, and also there's a loss of 
information when this happens (think base URIs). I suggest not to design 
new APIs that *require* following redirects, as "transparently" doesn't 
really work. Also, existing APIs should be adapted so that the caller 
can switch off redirect following, or at least get information about 
what has happened (minimally the new URI, probably also the type of 
redirect).

> Should we also fail if the response code is 310?

Fail means "network error" with no means for the caller to find out 
what's wrong? This seems to be the worst possible solution (as compared 
to following, or not following and giving the caller sufficient 
information about what to do next).

> follow redirects for status codes other than 301, 302, 303, and 307?

That's issue #325.

> of the "blessed redirects" anymore.

In which case you should consider allowing the caller to choose whether 
to follow redirects or not.

> I could not find the issue.

There doesn't seem to be an issue in the tracker; I'll leave it to Mark 
to decide how to proceed.

In general, HTTP is relatively silent on what UAs need to do with a 
response, it prefers just to describe the semantics of the message. With 
respect to new 3xx codes, we really should say whether they fall into 
the 301/302/307 bucket or not (see 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-17.html#rfc.section.7.3> 
for relatively new text trying to introduce 3xx categories).

With respect to re-sending header fields, this is related to issue 
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/22> which is about 
classifying header fields (which may be the reason why Mark thought we 
don't need an extra issue).

Best regards, Julian

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 07 Dec 2011 00:56:14 +1300

On 7/12/2011 12:14 a.m., Anne van Kesteren wrote:
> transparent redirects (redirects automatically followed by the API) 
> what exactly should count as a redirect as far as they are concerned? 
> http://dvcs.w3.org/hg/cors/raw-file/tip/Overview.html#actual-request 
> we explicitly fail if the response code is 301, 302, 303, or 307, 
> because we want the ability to support transparent redirects going 
> forward. Should we also fail if the response code is 310?

HTTP has always specified that any unknown code is to be treated as if 
it was the x00 status of the matching numeric group. This has not changed.

For the 3xx group 300 is defined as representing any one or more 
alternatives. If a Location header is present it is the alternative 
location of one representation, and MAY be used for automatic redirection.
http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-17#section-7.3.1

AYJ

> Should it instead treat anything else as a network error so we can 
> more easily extend it in the future? If we do not treat it as a 
> network error the developer would just get back a response with a 
> status code of 310 and the Location header and going forward we could 
> never treat it as any of the "blessed redirects" anymore.
>
>
> Aside: What happened to 
> http://lists.w3.org/Archives/Public/ietf-http-wg/2011JulSep/0014.html 
> ? I could not find the issue.
>
>

---

From: Julian Reschke <[email-masked]>
Date: Tue, 06 Dec 2011 13:12:18 +0100

On 2011-12-06 12:56, Amos Jeffries wrote:
> ...

Well, at least for 3xx, this seems to be the worst possible choice. It 
makes it extremely hard to introduce any new 3xx code which is not 
identical to 300.

Best regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 6 Dec 2011 16:20:10 -0800

On Dec 6, 2011, at 4:12 AM, Julian Reschke wrote:
> Well, at least for 3xx, this seems to be the worst possible choice. It makes it extremely hard to introduce any new 3xx code which is not identical to 300.

I disagree.  All 3xx codes are redirects and only some of those MAY
be followed with automatic redirection -- the ones with a Location
header field indicating the preferred redirect target.  The default
behavior applies if the recipient does not know the new code.

Extension codes will want one default behavior or the other, and
use Location accordingly.  If the client does understand the new
status code, then it will perform the process defined by that code
(which won't conflict with the default unless something invalid
is specified, like trying to reuse Location for some other purpose).

As Julian mentioned, this does not mean that XHR should automagically
follow redirects without the caller knowing the new URI -- that simply
won't work without corresponding magic content editing or a blanket
prohibition on relative references within the content.

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 7 Dec 2011 12:42:50 +1100

On 06/12/2011, at 10:22 PM, Anne van Kesteren wrote:

> On Tue, 06 Dec 2011 12:14:24 +0100, Anne van Kesteren <[email-masked]> wrote:
>> When we design APIs (XMLHttpRequest) and protocols (CORS) that support transparent redirects (redirects automatically followed by the API) what exactly should count as a redirect as far as they are concerned? Everything in the 3xx range that contains a Location header?
>> 
>> E.g. for some part of CORS http://dvcs.w3.org/hg/cors/raw-file/tip/Overview.html#actual-request we explicitly fail if the response code is 301, 302, 303, or 307, because we want the ability to support transparent redirects going forward. Should we also fail if the response code is 310?
>> 
>> Should http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#same-origin-request-event-rules follow redirects for status codes other than 301, 302, 303, and 307? Should it instead treat anything else as a network error so we can more easily extend it in the future? If we do not treat it as a network error the developer would just get back a response with a status code of 310 and the Location header and going forward we could never treat it as any of the "blessed redirects" anymore.
> 
> It seems this question is related to http://trac.tools.ietf.org/wg/httpbis/trac/ticket/325

Yes.

>> Aside: What happened to http://lists.w3.org/Archives/Public/ietf-http-wg/2011JulSep/0014.html ? I could not find the issue.
> 
> I could not find this issue in your database or in the mailing list archives since mnot said he would raise it. It was more or less by chance that I happened to look at it again because I vaguely recalled having raised a redirect issue earlier. I guess I did not use "NEW ISSUE" but then I did not know whether it was an issue when I started the thread. Can someone please fix this now?

Sorry, Anne; I couldn't find it either, so I've just created <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/328>.

The discussion wound up here: <http://www.w3.org/mid/[email-masked]>. As others have mentioned, I don't think there's much we can say about this, other than mentioning it as something that people who define new headers should consider.

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

---

From: Julian Reschke <[email-masked]>
Date: Wed, 07 Dec 2011 09:46:09 +0100

> behavior applies if the recipient does not know the new code.

Indeed:

"If the server has a preferred choice of representation, it SHOULD 
include the specific URI for that representation in the Location field; 
user agents MAY use the Location field value for automatic redirection."

So for new 3xx responses that come with "Location", UAs MAY use it for 
automatic redirection. But then, they don't have to.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 7 Dec 2011 19:53:06 +1100

On 07/12/2011, at 7:46 PM, Julian Reschke wrote:
> "If the server has a preferred choice of representation, it SHOULD include the specific URI for that representation in the Location field; user agents MAY use the Location field value for automatic redirection."
> 
> So for new 3xx responses that come with "Location", UAs MAY use it for automatic redirection. But then, they don't have to.

So, it sounds like we need a new paragraph (or similar) in p2 8.3 redirection...

---

From: Julian Reschke <[email-masked]>
Date: Wed, 07 Dec 2011 10:06:05 +0100

> So, it sounds like we need a new paragraph (or similar) in p2 8.3 redirection...

To say what?

A 3xx with Location is more like 302 then 300?

Best regards, Julian

---

From: "Anne van Kesteren" <[email-masked]>
Date: Wed, 07 Dec 2011 10:53:54 +0100

On Wed, 07 Dec 2011 02:42:50 +0100, Mark Nottingham <[email-masked]> wrote:
> Sorry, Anne; I couldn't find it either, so I've just created  
> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/328>.
>
> The discussion wound up here:  
> <http://www.w3.org/mid/[email-masked]>. As  
> others have mentioned, I don't think there's much we can say about this,  
> other than mentioning it as something that people who define new headers  
> should consider.

Is that another way of saying we should define the behavior in the HTML  
fetch algorithm?

---

From: Julian Reschke <[email-masked]>
Date: Wed, 07 Dec 2011 12:57:48 +0100

On 2011-12-07 10:53, Anne van Kesteren wrote:
>> others have mentioned, I don't think there's much we can say about
>> this, other than mentioning it as something that people who define new
>> headers should consider.
>

My understanding is that it depends, and needs to decided on a 
per-header basis. We can try classifications that make it easier to 
decide, and we may even be able to recommend a default, but this will 
break when a new header needs the non-default behavior.

The base issue is splitting the responsibilities between two layers, and 
have the lower layer (XHR) trying to decide things that the upper layer 
(the script) should know.

I'm not sure what this has to do with "HTML Fetch", as the problem is 
specific to XHR. I recommend to fix the base issue first, which is that 
clients can't ask XHR not to follow redirects.

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 7 Dec 2011 14:45:27 +0100

Hi Julian,

> A 3xx with Location is more like 302 then 300?

I don't think we should say something like this. For instance a new 3xx
might provide a Location header which would only be conditionnally used.
Requiring UAs to process 3xx like 302 if they see a Location header seems
problematic for the long term.

Why not say that a Location header might be used in conjunction with new 3xx
headers but UAs must not use it unless they understand this 3xx ?

Regards,
Willy

---

From: Julian Reschke <[email-masked]>
Date: Wed, 07 Dec 2011 15:08:30 +0100

> headers but UAs must not use it unless they understand this 3xx ?

Well, the question is what UAs should do with a 3xx + Location. AFAIR, 
Safari follows the redirect, while others do not.

Safari's behavior is "good" as it would allow to define 308 (as the 
permanent version of 307), and nothing needs to be changed in the browser.

Best regards, Julian

---

From: "Anne van Kesteren" <[email-masked]>
Date: Wed, 07 Dec 2011 16:22:54 +0100

> break when a new header needs the non-default behavior.

I don't think that will work for us. It needs to be the same irrespective  
of the header. Or some kind of fixed unchanging list for which things is  
different.

> clients can't ask XHR not to follow redirects.

XMLHttpRequest uses HTML fetch. Server-sent events does too, and a number  
of other things affected do so as well. You indeed keep bringing up that  
we should add a feature to XMLHttpRequest and that it will resolve the  
problem. But adding a feature does not resolve the problem. We will still  
have the problem for when such a feature is not used. So lets address  
that. Adding a feature for redirects is completely orthogonal as I  
explained several times now. I am getting somewhat tired of having to  
repeat myself.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 07 Dec 2011 16:31:33 +0100

On 2011-12-07 16:22, Anne van Kesteren wrote:
> On Wed, 07 Dec 2011 12:57:48 +0100, Julian Reschke
> <[email-masked]> wrote:
> I don't think that will work for us. It needs to be the same
> irrespective of the header. Or some kind of fixed unchanging list for
> which things is different.
> ...

Well, it seems that "what it needs to be" is not compatible with how 
HTTP works. I have no idea how to address this kind of requirement.

Best regards, Julian

---

From: Cameron Heavon-Jones <[email-masked]>
Date: Wed, 7 Dec 2011 15:43:13 +0000

On 07/12/2011, at 2:08 PM, Julian Reschke wrote:

> Well, the question is what UAs should do with a 3xx + Location. AFAIR, Safari follows the redirect, while others do not.
> 
> Safari's behavior is "good" as it would allow to define 308 (as the permanent version of 307), and nothing needs to be changed in the browser.
> 
> Best regards, Julian
> 

these test results might be of interest:

http://www.cmhjones.com/browser-http-test-matrix.html

thanks,
cameron

---

From: Julian Reschke <[email-masked]>
Date: Wed, 07 Dec 2011 16:50:39 +0100

> http://www.cmhjones.com/browser-http-test-matrix.html

...so Safari follows an unknown redirect only if the response doesn't 
have a payload.

Best regards, Julian

---

From: Cameron Heavon-Jones <[email-masked]>
Date: Wed, 7 Dec 2011 15:54:30 +0000

On 07/12/2011, at 3:50 PM, Julian Reschke wrote:

> ...so Safari follows an unknown redirect only if the response doesn't have a payload.
> 
> Best regards, Julian
> 

yes, that's correct. 

as a general observation, a payload will tend get priority and be rendered.

thanks,
cam

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 8 Dec 2011 11:59:16 +1100

On 08/12/2011, at 2:22 AM, Anne van Kesteren wrote:

> On Wed, 07 Dec 2011 12:57:48 +0100, Julian Reschke <[email-masked]> wrote:
>> My understanding is that it depends, and needs to decided on a per-header basis. We can try classifications that make it easier to decide, and we may even be able to recommend a default, but this will break when a new header needs the non-default behavior.
> 
> I don't think that will work for us. It needs to be the same irrespective of the header. Or some kind of fixed unchanging list for which things is different.

Unfortunately, that's how it works. 

Consider -- right now, for every request, implementations decide what headers to send, based upon a number of factors. There are a very few that are required by HTTP (e.g., Host), many that are optional, depending upon the implementation (e.g., Connection, Accept-*, User-Agent), some that depend upon the situation (e.g., Referer), the internal state of the client (e.g., Authorization, If-Modified-Since, If-None-Match), or the request itself (e.g., If-Match, Content-Type).

All of these considerations apply to redirect requests as well. 

>> The base issue is splitting the responsibilities between two layers, and have the lower layer (XHR) trying to decide things that the upper layer (the script) should know.
>> 
>> I'm not sure what this has to do with "HTML Fetch", as the problem is specific to XHR. I recommend to fix the base issue first, which is that clients can't ask XHR not to follow redirects.
> 
> XMLHttpRequest uses HTML fetch. Server-sent events does too, and a number of other things affected do so as well. You indeed keep bringing up that we should add a feature to XMLHttpRequest and that it will resolve the problem. But adding a feature does not resolve the problem. We will still have the problem for when such a feature is not used. So lets address that. Adding a feature for redirects is completely orthogonal as I explained several times now. I am getting somewhat tired of having to repeat myself.

OK. We seem to be repeating ourselves as well; the solution you're looking for isn't in this direction, at least as far as we can see.

If you'd like to make a concrete proposal, we'd be more than happy to discuss it, but keep in mind that to be in the HTTP spec, it needs to be applicable to all uses of HTTP, not just a subset of them.

Cheers,

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

---

From: "Anne van Kesteren" <[email-masked]>
Date: Thu, 08 Dec 2011 18:27:57 +0100

On Thu, 08 Dec 2011 01:59:16 +0100, Mark Nottingham <[email-masked]> wrote:
> Consider -- right now, for every request, implementations decide what  
> headers to send, based upon a number of factors. There are a very few  
> that are required by HTTP (e.g., Host), many that are optional,  
> depending upon the implementation (e.g., Connection, Accept-*,  
> User-Agent), some that depend upon the situation (e.g., Referer), the  
> internal state of the client (e.g., Authorization, If-Modified-Since,  
> If-None-Match), or the request itself (e.g., If-Match, Content-Type).
>

That makes a lot of sense to me and for headers that are integral part of  
the protocol I agree they might differ per request.

This question in particular is for higher level API that implements the  
protocol and automatically follows redirects, but does not implement the  
protocol's extensions (either standardized, like WebDAV, or proprietary,  
such as X-User-Screen-Size). The library should of course set the basic  
headers as appropriate depending on what the request URL ends up being.  
But it seems to me than other than that it can only repeat the request to  
the new URL.

> If you'd like to make a concrete proposal, we'd be more than happy to  
> discuss it, but keep in mind that to be in the HTTP spec, it needs to be  
> applicable to all uses of HTTP, not just a subset of them.

It seems the path of least resistance here is that XMLHttpRequest defines  
that "author request headers" (headers authors can set) are included in  
the request to the new URL. That HTML defines that Last-Event-ID for  
EventSource is included when there's a redirect. That Ping-To and  
Ping-From are included.

Since all these go through HTML fetch it may turn out that for the  
purposes of HTML fetch additional headers set should always be included in  
redirects.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 9 Dec 2011 16:41:28 +1100

On 09/12/2011, at 4:27 AM, Anne van Kesteren wrote:

> That makes a lot of sense to me and for headers that are integral part of the protocol I agree they might differ per request.
> 
> This question in particular is for higher level API that implements the protocol and automatically follows redirects, but does not implement the protocol's extensions (either standardized, like WebDAV, or proprietary, such as X-User-Screen-Size). The library should of course set the basic headers as appropriate depending on what the request URL ends up being. But it seems to me than other than that it can only repeat the request to the new URL.

Or omit it.

Consider Cookie, for example -- which isn't part of HTTP, but is an extension (albeit widely-used). It effectively implements its own protocol, and it would be surprising (possibly disastrous) if you blindly copied a cookie from one domain to another upon a redirect.

That doesn't happen, of course, because browsers implement and understand cookies; likewise, I'd expect that any other code in a browser handling a specific header-based protocol would deal with redirects as a consequence of how it's implemented.

The tricky bit is when people want to implement such protocols using just XHR, rather than have the browser handle them. 

> It seems the path of least resistance here is that XMLHttpRequest defines that "author request headers" (headers authors can set) are included in the request to the new URL. That HTML defines that Last-Event-ID for EventSource is included when there's a redirect. That Ping-To and Ping-From are included.

That seems reasonable. 

> Since all these go through HTML fetch it may turn out that for the purposes of HTML fetch additional headers set should always be included in redirects.

OK. I'm going to close the ticket with no change, unless I hear otherwise from you.

Note that we've already incorporated some text here:

>    Authors of specifications defining new header fields are advised to
>    consider documenting:
[...]
>    o  Whether the header field should be preserved across redirects.

<http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-17#section-3.1>

Cheers,

---

From: Herbert van de Sompel <[email-masked]>
Date: Fri, 9 Dec 2011 10:44:02 -0700

Dear all,

I hope that it's useful to share our experiences with redirects in the
Memento "Time Travel for the Web" project [1] and the development of
Memento clients such as the FireFox add-on MementoFox [2]:

1. Being able to intercept HTTP requests in the client at every step is
critically important for us in order to be able to accurately navigate to
prior versions of resources.  Please imagine the following case:
- 12 months ago, a given URI (R1) redirected to a particular image (I1).
- Today, it redirects to a different image (I2).
In order for a Memento client to be able to retrieve the image that was the
end result of the redirect 12 months ago (I1), it must be able to intercept
the first URI requested (R1) and start time traveling from there. Indeed,
if not intercepting the first URI and hence following the redirect chain,
the Memento client would end up at image I2, which was not the active
resource 12 months ago.
As it is important to be able to do this same interception for any HTTP
request, automatically and unpreventably following links in XMLHttpRequest
or any other context is very disruptive.

2. There is another issue regarding automatic following, which is possibly
tangential to the current discussion, but we feel is worth bringing up.
 The Link Header RFC [3] allows target URIs to be associated in the HTTP
headers with the responding resource.  It would be very useful if users
could set preferences to allow following these links, even if the response
is not a 3XX status. In Memento clients, this would allow to e.g. follow a
link to a TimeGate.

Thank you for the consideration,

Herbert Van de Sompel, Michael Nelson, Robert Sanderson

[1] Memento:  http://mementoweb.org/ ; Internet Draft:
https://datatracker.ietf.org/doc/draft-vandesompel-memento/
[2] https://addons.mozilla.org/en-US/firefox/addon/mementofox/
[3]RFC5988: http://tools.ietf.org/html/rfc5988

-- 
Herbert Van de Sompel
Digital Library Research & Prototyping
Los Alamos National Laboratory, Research Library
http://public.lanl.gov/herbertv/

==

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 14 Dec 2011 15:47:46 +1100

Do we have agreement that a 3xx + Location can / should trigger an automatic redirect (taking into account user notification -- a separate issue)?

Regards,

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 14 Dec 2011 07:43:24 +0100

Hi Mark,

> Do we have agreement that a 3xx + Location can / should trigger an automatic redirect (taking into account user notification -- a separate issue)?

While I have no strong feeling about it, I still think it's not the best
idea for the long term. While Julian suggests Safari's behaviour is good,
I'd see it differently, considering that it handles 3xx like 302 and
differently from 300 (in fact, only Chrome seems to be consistent between
3xx and 300 in Cameron's tests).

The only thing I don't like with saying that Location will be usable with
all 3xx is that it basically means that we won't create any new 3xx anymore,
because once we have the various basic redirects, we'll stop there. Without
suggesting an automatic redirect, we could imagine that later we'd add a
status with multiple Location headers and let the user pick one, or another
status indicating a unsafe/expensive locations which require user approval,
or any such thing. If we perform the automatic redirect, we'll refrain from
adding such codes, or we'll have to invent a new header.

For instance, imagine that all the user manual of your mobile phone is
supposed to be accessible from within it, with some pages cached inside
and other ones outside. You could have a small server in it which either
serves the cached pages when it has them (or redirects to their local
filesystem location using 301), or suggests a redirect to the external
site to fetch them. But you wouldn't necessarily want the user to
retrieve large amounts of data from the net without being aware of it,
since it can be very expensive depending where you are. A user-approved
redirect would perfectly make sense here.

Another example I'm facing very often is that developers working on
http+https applications generally need to know both the protocol used
and the host, while it's not always easy where the app is located.
Adding new extensions which would mean "redirect to same host using
https" or "same scheme with host xxx" or even "same host + port XYZ"
would sometimes help a lot. I'm not sure we'll be able to add them
after suggesting an automatic rule.

Once again, I have no strong feeling about it and I'm not a browser
developer, but I'm just trying to keep some rope for future additions.
If everyone else is OK with the automatic redirect on 3xx, I won't insist.

If I had the choice, I'd rather suggest either that a UA MAY automatically
redirect, or that it SHOULD redirect with user approval ; both options would
keep server implementers from inventing their own codes every day, without
blocking evolutions.

Best regards,
Willy

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 14 Dec 2011 21:58:23 +1100

Hi Willy,

How is Safari's behaviour more like handling 302 than 300? 300 states:

>    If the server has a preferred choice of representation, it SHOULD
>    include the specific URI for that representation in the Location
>    field; user agents MAY use the Location field value for automatic
>    redirection.

Also, the use cases you talk about could be addressed by using a header other than Location (i.e., omitting Location from a 3xx response), just as 304 does.

Cheers,

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 14 Dec 2011 15:09:22 +0100

> >    field; user agents MAY use the Location field value for automatic

In Cameron's matrix it's indicated that Safari does not redirect on 300,
while it does on almost all 3xx except 304. If we're logical, it should
apply the 300 rule to all unknown 3xx.

> Also, the use cases you talk about could be addressed by using a header other than Location (i.e., omitting Location from a 3xx response), just as 304 does.

Indeed, we could do that too.

Best regards,
Willy

---

From: Cameron Heavon-Jones <[email-masked]>
Date: Wed, 14 Dec 2011 16:02:34 +0000

Hi Mark et al,

> Do we have agreement that a 3xx + Location can / should trigger an automatic redirect (taking into account user notification -- a separate issue)?

If i may provide some observations wrt browser clients and the tests performed to determine the current state of interpretation of http spec and resulting implementation of response handling.

The most interesting aspect for me was the difference between content vs no-content responses. This is the area of greatest complementary implementation behaviour across vendors, and for good reason.

The behaviour of a client in response to redirection codes should not be specified in http as this is dependant on the type of client and its role and responsibly for the end user.

In the case of a browser, the end user is the decision maker and overarching authority over the request and response. for this reason, i believe current behaviour exhibited by *all* implementations is the natural, and correct, behaviour - if content is supplied in response body, terminate any further processing and render the content for the end user to make a decision. 

this provides the mechanism for severs to return the appropriate response status but also to over-ride any automatic handling with the ability to provide custom content describing the nature of the response and any further actions that may optionally be followed and with full description of how or why in rendered media format. possibly this addresses the separate issue of user notification?

the case of what should be default behaviour for 3xx without content or for non-interactive clients is more nuanced. safari has chosen to implement automatic redirects, no doubt from apple's philosophy on interface interaction which is seen throughout their products.

my personal take is that as we already have redirection codes which are automatically followed, to apply as a default for new status codes doesn't really achieve anything we don't already have, yet as noted, an automatic following of redirection may limit future specification and diverges from all other default behaviour which tends to be - if you don't know what it is, don't do anything.

as a member of HTML WG and through working through specifying additional methods on forms, the handling of responses by browsers has been highlighted as an area requiring attention, and potential specification. given that XHR specification includes response handling behaviour, html spec would also seem to be the place for specifying this in the case of rendered html pages. this is currently being looked at under bug 10671 [1].

in the case of XHR, i believe that appropriate callbacks should be sufficient in allowing all use cases to be covered, there are some security concerns regarding cross origin redirection however knowledge of this on the part of the server should be sufficient in the design of these services. I am unsure as to re-applying headers from one request to another on a different domain - the script has setup the appropriate request including custom headers and based on all of this information the server chooses the appropriate response. to start mixing requests sounds a little strange, for scripts an alternative is surely for the server not to return an auto-redirect and instead return the URI and allow the script to setup the appropriate request.

thanks,
Cameron Jones

---

From: Julian Reschke <[email-masked]>
Date: Wed, 14 Dec 2011 17:14:27 +0100

> In the case of a browser, the end user is the decision maker and overarching authority over the request and response. for this reason, i believe current behaviour exhibited by *all* implementations…

Wait a minute.

I thought UAs follow 301/302/307 even when sent with content?

Also, XHR follows all of these automatically (and no, it should not).

Best regards, Julian

---

From: Cameron Heavon-Jones <[email-masked]>
Date: Wed, 14 Dec 2011 16:26:34 +0000

On 14/12/2011, at 4:21 PM, Cameron Heavon-Jones wrote:
> On 14/12/2011, at 4:14 PM, Julian Reschke wrote:
> 
>>>  render the content for the end user to make a decision.
>> 
>> Wait a minute.
>> 
> No, check the first table - almost all tests result in rendered content apart from 304 and IE throwing some errors.

FYI - the test results table being referenced is here:

And the HTML bug on form methods is here:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=10671

Thanks,
Cam

---

From: Cameron Heavon-Jones <[email-masked]>
Date: Wed, 14 Dec 2011 16:21:27 +0000

Thanks,
Cam

---

From: Julian Reschke <[email-masked]>
Date: Wed, 14 Dec 2011 17:30:39 +0100

> No, check the first table - almost all tests result in rendered content apart from 304 and IE throwing some errors.

Ack.

But this is for *POST* only, right?

Best regards, Julian

---

From: Cameron Heavon-Jones <[email-masked]>
Date: Wed, 14 Dec 2011 17:04:01 +0000

> But this is for *POST* only, right?

I don't think it makes a difference, a response should be parsed irrespective of the request although i don't know that this is definitively the case.

I just checked Firefox and the same behaviour is seen, i would assume the same from the other browsers but i can do more tests to confirm.

Thanks,
Cam

---

From: Julian Reschke <[email-masked]>
Date: Wed, 14 Dec 2011 18:13:42 +0100

> I just checked Firefox and the same behaviour is seen, i would assume the same from the other browsers but i can do more tests to confirm.

What exactly did you check?

I'm VERY sure that browsers automatically follow a 302 + Location upon 
page navigation, no matter whether there's a payload or not.

Best regards, Julian

---

From: Cameron Heavon-Jones <[email-masked]>
Date: Wed, 14 Dec 2011 17:35:47 +0000

On 14/12/2011, at 5:13 PM, Julian Reschke wrote:

> I'm VERY sure that browsers automatically follow a 302 + Location upon page navigation, no matter whether there's a payload or not.
> 
> Best regards, Julian

I setup the same form i used testing POST to encode into URI instead of form params and sent as GET. It produced a URI like this:

http://localhost:8090/web/test/it?status=302&location=http%3A%2F%2Fwww.example.com&content=on

The response was the same as for POST, ie:

HTTP/1.1 302 Found
Location        http://www.example.com
Content-Type    text/html
Content-Length  199
Server          Jetty(6.1.7)
				
<html>
    <body>
        <h1>Response</h1>
        <p>Response Status: 302</p>
        <p>Response Reason: Found</p>
    </body>
</html>

I don't think there's anything else?

Thanks,
Cam

---

From: Daniel Stenberg <[email-masked]>
Date: Wed, 14 Dec 2011 19:47:38 +0100 (CET)

On Wed, 14 Dec 2011, Cameron Heavon-Jones wrote:

>> I'm VERY sure that browsers automatically follow a 302 + Location upon page 
>> navigation, no matter whether there's a payload or not.
>

For the fun of it I just now fired off Chrome and Firefox against a 302 with 
content and they redirected automatically. curl also works the same way.

The CGI interface used with for example Apache even inserts contents by itself 
and that has not caused a problem to browsers for a very long time, neither on 
POST nor GET responses.

Something is seriously wrong with the tests if they come to another 
conclusion.

-- 

  / daniel.haxx.se

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 14 Dec 2011 20:28:42 +0100

On Wed, Dec 14, 2011 at 07:47:38PM +0100, Daniel Stenberg wrote:
> For the fun of it I just now fired off Chrome and Firefox against a 302 
> with content and they redirected automatically. curl also works the same 
> way.

Confirmed here with FF 3.6 and IE 6.0 on GET + 302 + Content. I've tried
to redirect to a non-responding location to see if anything was displayed
during the connection attempt, but there was nothing either.

Regards,
Willy

---

From: Cameron Heavon-Jones <[email-masked]>
Date: Wed, 14 Dec 2011 21:46:31 +0000

On 14/12/2011, at 6:47 PM, Daniel Stenberg wrote:

> For the fun of it I just now fired off Chrome and Firefox against a 302 with content and they redirected automatically. curl also works the same way.
> 
> The CGI interface used with for example Apache even inserts contents by itself and that has not caused a problem to browsers for a very long time, neither on POST nor GET responses.
> 
> Something is seriously wrong with the tests if they come to another conclusion.
> 
> -- 
> 
> / daniel.haxx.se

I'm more that willing to accept if there is some fallibility in the tests and its great that there is validation. I'm seriously unsure where such error may be since i've been tracing http request\responses through in-browser network tools. i'm going to repeat capturing whats on the wire instead and if i still can't find the same results i'll setup a public test case which everyone can use.

thanks,
cam

---

From: Daniel Stenberg <[email-masked]>
Date: Wed, 14 Dec 2011 23:11:58 +0100 (CET)

On Wed, 14 Dec 2011, Cameron Heavon-Jones wrote:

> I'm more that willing to accept if there is some fallibility in the tests 
> and its great that there is validation. I'm seriously unsure where such 
> error may be since i've been tracing http request\responses through 
> in-browser network tools. i'm going to repeat capturing whats on the wire 
> instead and if i still can't find the same results i'll setup a public test 
> case which everyone can use.

Pick your browser of choice and click on this link for a GET test:

 	http://daniel.haxx.se/test/redir.cgi

And you can POST to the same URL by using this form:

 	http://daniel.haxx.se/test/redir.html

(It returns a 302 redirect with 282 bytes of contetns. It redirects to 
http://example.com/funny/page.html)

-- 

  / daniel.haxx.se

---

From: Cameron Heavon-Jones <[email-masked]>
Date: Thu, 15 Dec 2011 15:23:48 +0000

On 14/12/2011, at 10:11 PM, Daniel Stenberg wrote:

> (It returns a 302 redirect with 282 bytes of contetns. It redirects to http://example.com/funny/page.html)
> 
> -- 
> 
> / daniel.haxx.se

I have found the source of the errors in the test results which was due to a bug in the test harness affecting >10% cases which were testing the unique combination of redirection codes, location headers AND content. the bug arose through recent expansion of the test coverage which included testing some non-standard responses. the erroneous results can be regarded as non-conformance tests over redirection codes without a location header.

i've since fixed the bug and confirmed the same results that were expected by expertise field knowledge. its a good catch and i'm really glad that it was found as incorrect results are far worse than no results. the tests were setup precisely to determine field behaviour where such preexisting knowledge did not exist. 

the unexpected nature of the results was the very reason that i thought pertinent to bring to the discussion, since the results are incorrect, both them and my resulting observations and analysis should be disregarded.

i've repeated the affected tests and updated the matrix with the correct results. 

Thanks,
Cameron Jones

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 29 Dec 2011 19:43:15 -0500

One other thing --

p2 already has:

> For 3xx responses, the location SHOULD indicate the server's preferred URI for automatic redirection to the resource.

There was equivalent text in 2616. So, I think the resolution here is actually pretty minor; we just need to add text to p2 7.3 that reflects this; e.g.,

"""A Location header on a 3xx response indicates that a client MAY automatically redirect to the URI provided; see [ref to Location header]."""

Comments?

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

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 30 Dec 2011 07:09:45 +0100

> """A Location header on a 3xx response indicates that a client MAY automatically redirect to the URI provided; see [ref to Location header]."""

Works for me.

Regards,
Willy

---

From: Julian Reschke <[email-masked]>
Date: Fri, 30 Dec 2011 15:54:51 +0100

> """A Location header on a 3xx response indicates that a client MAY automatically redirect to the URI provided; see [ref to Location header]."""

But that just repeats something the definition of 300 already says, right?

"If the server has a preferred choice of representation, it SHOULD 
include the specific URI for that representation in the Location field; 
user agents MAY use the Location field value for automatic redirection." 
-- 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-17.html#rfc.section.7.3.1.p.3>

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 30 Dec 2011 09:56:01 -0500

On 30/12/2011, at 9:54 AM, Julian Reschke wrote:

> "If the server has a preferred choice of representation, it SHOULD include the specific URI for that representation in the Location field; user agents MAY use the Location field value for automatic redirection." -- 

Right, but we want to make it clear that this applies to 3xx generically.

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

---

From: Julian Reschke <[email-masked]>
Date: Fri, 30 Dec 2011 17:48:24 +0100

> Right, but we want to make it clear that this applies to 3xx generically.

Ok, works for me.

Proposed patch: 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/325/325.diff>

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 31 Dec 2011 10:44:03 -0500

Looks good to me.

On 30/12/2011, at 11:48 AM, Julian Reschke wrote:

> Proposed patch: <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/325/325.diff>
> 
> Best regards, Julian
> 

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