- From: Anne van Kesteren <annevk@opera.com>
- Date: Mon, 11 Jul 2011 16:32:10 +0200
- To: "Darin Fisher" <darin@chromium.org>
- Cc: "Julian Reschke" <julian.reschke@gmx.de>, "Mark Baker" <distobj@acm.org>, "HTTP WG" <ietf-http-wg@w3.org>, "Mark Nottingham" <mnot@mnot.net>
On Wed, 06 Jul 2011 19:12:28 +0200, Darin Fisher <darin@chromium.org> wrote: > 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. 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. > 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. Feel free to suggest that on public-webapps@w3.org. Though please include use cases. >> 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." > > 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. -- Anne van Kesteren http://annevankesteren.nl/
Received on Monday, 11 July 2011 14:32:46 UTC