This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I tried to find a better place to file this but I wasn't able to find it. I'd like to suggest to extend the specification http://www.w3.org/TR/XMLHttpRequest/ ->3. The XMLHttpRequest Interface and in: 3.6.4. Infrastructure for the send() method If the response has an HTTP status code of 301, 302, 303, or 307 Proposal: Add the an attribute: readwrite attribute followRedirects What does it do? This attribute states if the browser should follow location headers or not. This attribute is only writable while state = 0. This attribute defaults to true (for backwards compatibility and because the usual use is to work like this). Why am I asking for this: I have been writing browser addons for a while and now I'm writing another one that uses unrestricted cross origin XMLHttpRequest(). The problem is that the page I want may return: 200, 302 or 304. When it returns 302 (usually) it redirects to a page that returns 302 and this repeats 2 more times. When there is a redirection, I'm not interested anymore because it won't have the content I want. My solution, for now: 1. Make the XMLHttpRequest() 2. Check the status code (for 200 or 304) 3. If it's 304, abort. 4. Execute a regex to check the responseText for a match. 5. If it's a match, then execute the code it should, else abort. Problem: With all those redirects, the time the script uses, the CPU it uses and the number of requests it must make makes this background extension a really heavy duty for something as small as this is. If this is approved I can make a much better code: 1. Make the XMLHttpRequest() 2. Check the status code (for 200, 302 or 304) 3. if it's 302 or 304 abort 4. execute the code it should No regex -> Much faster code No unecessary redirects -> Does not occupy the connections unecessary -> Much faster code and more proper background execution.
Note that if your addon is a Mozilla addon it can already prevent XHR from redirecting.
(In reply to comment #1) > Note that if your addon is a Mozilla addon it can already prevent XHR from > redirecting. This one is a chrome extension.
(In reply to comment #2) > (In reply to comment #1) > > Note that if your addon is a Mozilla addon it can already prevent XHR from > > redirecting. > > This one is a chrome extension. I tried looking about this in the mozilla docs and I found nothing about how to prevent that redirection. Anyway, I think it would be useful to create a spec for it so that it would be normalized
In Mozilla, you can just register a redirect observer directly on the underlying nsIChannel.
This is for the WebApps WG.
See the archives of public-webapps@w3.org. Finding the right way to do this was harder than initially thought so the idea has been dropped for now. Having said that, extensions are not a use case for web platform extensions.
In particular anything we do here should take http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/thread.html#msg474 into consideration and in particular the emails from Darin Fisher.
*** Bug 17046 has been marked as a duplicate of this bug. ***
I have a proposal that is similar to one originally brought up on the mailing list, but a bit different (I suspect Mozilla's implementation already works this way). Instead of adding a "followRedirects" flag and forcing users to issue new requests at each "redirect hop", add a "redirect observer" as follows: 1. Allow users to register an event listener. 2. Every time the server returns a response, the event listener is fired with the response body and headers. 3. At this point, the listener may allow the request to continue or terminate it. 4. If the listener terminated the request, set readyState to some value that indicates the process was "terminated by the user". 5. If the listener allows the request to continue and the response required a redirect, issue the new request and go to step #2. 6. Eventually no more redirects occur, and readyState is set to DONE as usual. This would have the nice side-effect of addressing bug #23361 which I just filed. Does this address everyone's use-cases? I read the mailing list posts at http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/thread.html#msg474 but it wasn't clear why "followRedirects" ended up being removed from the standard. Anne, could you shed some light?
Unfortunately redirects have to be atomic. See bug 24375.
Well, if authors can't control redirect behavior then the obvious alternate thing to ask for is to expose the redirect information after the request has finished. Does this have the same security concerns? If yes, we should have a precise description of what the problem is, so that a solution can address that.
I agree with Julian. This issue should be reopened and the browser should allow the user to read the final URL after redirection completes.
That is bug 15417.
I stand corrected. Thanks Anne.