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 UTC