Subject: Re: Redirects and headers

From: "Anne van Kesteren" <[email-masked]>
Date: Sat, 02 Jul 2011 10:16:15 +0200

On Tue, 28 Jun 2011 13:19:20 +0200, Mark Nottingham <[email-masked]> wrote:
> Julian pointed out that this was being discussed elsewhere, so I  
> tentatively added a note about this to our ticket #231, "Considerations  
> for new headers" <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/231>  
> earlier today.
>
> That helps for new headers, but of course it doesn't for existing ones.

It also does not help with experimental headers and headers that are not  
registered. And both of those are used with XMLHttpRequest. They should  
probably be covered by some fallback rule. The current consensus among  
browsers (Gecko changed recently) I believe is that those headers will  
make it through to the new request.

> In any case, I'll open a new issue shortly; thanks.

Cool!

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

---

From: Mark Baker <[email-masked]>
Date: Mon, 4 Jul 2011 10:34:13 -0400

FWIW, I can't, off-hand, think of anything that would need to be said
about this in the specification for the HTTP protocol.  The meaning of
the redirect should be clear from the definition of the status code,
and only the client is in a position to understand how to react to
such a message when crafting a follow-on request.

Mark.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 04 Jul 2011 17:15:04 +0200

> such a message when crafting a follow-on request.

Well, the issue is that we have middleware/tools that follow the 
redirect automatically (XHR), thus may not know that "the client's" 
intent was...

---

From: Mark Baker <[email-masked]>
Date: Mon, 4 Jul 2011 12:19:24 -0400

On Mon, Jul 4, 2011 at 11:15 AM, Julian Reschke <[email-masked]> wrote:
> Well, the issue is that we have middleware/tools that follow the redirect
> automatically (XHR), thus may not know that "the client's" intent was...

Understood. But IMO, the solution to the problem Anne describes is to
build a better API (and better implementations of that API).

Mark.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 04 Jul 2011 18:35:26 +0200

On 2011-07-04 18:19, Mark Baker wrote:
> On Mon, Jul 4, 2011 at 11:15 AM, Julian Reschke<[email-masked]>  wrote:

Agreed. But we have know this for many years, and yet nothing has 
happened with respect to this. :-(

---

From: Darin Fisher <[email-masked]>
Date: Mon, 4 Jul 2011 11:06:55 -0700

It seems like XHR's followRedirects attribute gives devs enough control
here.  XHR should at least document default header propagation behavior if
HTTP will not.
>>> Well, the issue is that we have middleware/tools that follow the
redirect

---

From: "Anne van Kesteren" <[email-masked]>
Date: Tue, 05 Jul 2011 11:36:45 +0200

On Mon, 04 Jul 2011 20:06:55 +0200, Darin Fisher <[email-masked]>  
wrote:
> here.  XHR should at least document default header propagation behavior  
> if HTTP will not.

followRedirects is out for now.

Anyway, there are plenty of other APIs too, e.g. EventSource. And even if  
we added functionality to XMLHttpRequest we would still need to define the  
default. Adding more features does not solve any existing problems.

And if this decision is entirely up to the APIs, please have the HTTP  
specification say so. E.g. "Note: Clients will have to decide which  
headers sent in the original request are used in the request to the  
redirected location."

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 5 Jul 2011 11:30:05 -0700

On Jul 5, 2011, at 2:36 AM, Anne van Kesteren wrote:
> And if this decision is entirely up to the APIs, please have the HTTP specification say so. E.g. "Note: Clients will have to decide which headers sent in the original request are used in the request to the redirected location."

Clients always decide what headers are used in a request.  The headers in the original request are only sent in the original request -- there is no connection between the two requests other than the original Location -> new request target and original request URI -> Referer.  Clients don't even have to make a subsequent request.

When a subsequent request is made, the client is probably in the same context as it was for the first request. That means it might still want to use image-specific Accept headers, special cache-control values, or whatever else it might have demanded in the first request.  Likewise, fields like Cookie are dependent on both the most recently set values and the domain of the new target URI.  But I don't have a way to say that in the spec which isn't redundant and useless handwaving, since the relevant header fields are very specific to what kind of client is being used and why the original request was made.

Clients are supposed to know what they want when a request is made.  There are no special protocol requirements here that are imposed on the client, aside from the normal HTTP request requirements.  We could have invented a field that indicates this request is an autofollowed redirect and then we could have mandated such a header field to be used in redirected requests, but there is no such field in HTTP/1.1, and thus if it were to be invented now it would have to be in a separate draft.

....Roy

---

From: Darin Fisher <[email-masked]>
Date: Wed, 6 Jul 2011 10:12:28 -0700

> followRedirects is out for now.

I see.  I was looking at an older version of the spec (
http://www.w3.org/TR/XMLHttpRequest2/#the-followredirects-attribute).

Do you have a pointer to the discussion about the removal of this feature?
 It seemed useful to me, although I had concerns that we didn't have a
companion method to help developers construct the redirect request.

> default. Adding more features does not solve any existing problems.

This is off-topic, but I think it is unfortunate that EventSource and XHR
don't share some common interface for configuring the underlying HTTP
request.  There's more than just redirect behavior that could be
interesting.  You also have custom HTTP request headers.

> specification say so. E.g. "Note: Clients will have to decide which headers
> sent in the original request are used in the request to the redirected
> location."

I agree with you that the HTTP spec should at least offer some guidance.  If
the HTTP spec is not going to describe what web browsers do in response to a
redirect, then what spec will cover that?  I agree that it is a crucial
detail.

-Darin

---

From: "Anne van Kesteren" <[email-masked]>
Date: Mon, 11 Jul 2011 16:24:24 +0200

On Tue, 05 Jul 2011 20:30:05 +0200, Roy T. Fielding <[email-masked]>  
wrote:
> Clients always decide what headers are used in a request.  The headers  
> in the original request are only sent in the original request -- there  
> is no connection between the two requests other than the original  
> Location -> new request target and original request URI -> Referer.   
> Clients don't even have to make a subsequent request.

Sure, but the specific case here is APIs that require clients to follow  
redirects. Should HTTP make designing those APIs easy by providing default  
handling for those APIs or should those APIs define the handling  
themselves?

In practice I assume that if HTTP is not going to address this we can add  
it to "fetch" algorithm currently defined in HTML. It would just be nice  
if the HTTP specification was more explicit on the matter.

---

From: "Anne van Kesteren" <[email-masked]>
Date: Mon, 11 Jul 2011 16:32:10 +0200

> companion method to help developers construct the redirect request.

I removed it because of your concerns about complexity for authors to deal  
with it themselves. It has not really come up since then so maybe it is  
not such a big deal. I am open to adding a more complicated API as you  
suggested at some point, but that needs a bit more thought.

> interesting.  You also have custom HTTP request headers.

Feel free to suggest that on [email-masked]. Though please include  
use cases.

>> redirected
> I agree with you that the HTTP spec should at least offer some  
> guidance.  If the HTTP spec is not going to describe what web browsers  
> do in response to a redirect, then what spec will cover that?  I agree  
> that it is a crucial
> detail.

I think we can probably put it in the "fetch" algorithm (see HTML) that  
most APIs use these days to describe requests if it is not going in the  
HTTP specification. It already has some prose around redirects.