W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2011

Re: Redirects and headers

From: Darin Fisher <darin@chromium.org>
Date: Mon, 4 Jul 2011 11:06:55 -0700
Message-ID: <CAP0-QpvPi748pJ4_SESgVmuk9Eu0=SNp9=zT1xgfdL+ky2XNBA@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Mark Baker <distobj@acm.org>, HTTP WG <ietf-http-wg@w3.org>, Anne van Kesteren <annevk@opera.com>, Mark Nottingham <mnot@mnot.net>
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.
On Jul 4, 2011 9:36 AM, "Julian Reschke" <julian.reschke@gmx.de> wrote:
> On 2011-07-04 18:19, Mark Baker wrote:
>> On Mon, Jul 4, 2011 at 11:15 AM, Julian Reschke<julian.reschke@gmx.de>
wrote:
>>> On 2011-07-04 16:34, Mark Baker wrote:
>>>>
>>>> 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.
>>>
>>> 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).
>
> Agreed. But we have know this for many years, and yet nothing has
> happened with respect to this. :-(
>
>
Received on Monday, 4 July 2011 18:07:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:43 GMT