12607 2011-05-05 12:33:52 +0000 Let authors control redirect behavior 2014-02-03 18:16:42 +0000 1 1 1 Unclassified WebAppsWG XHR unspecified PC Windows 3.1 RESOLVED WONTFIX P2 normal --- 1 brunoaiss annevk annevk baranovich brunoaiss bzbarsky cowwoc hsteen julian.reschke mike public-webapps public-webapps-bugzilla oldest_to_newest 48083 0 brunoaiss 2011-05-05 12:33:52 +0000 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. 48088 1 bzbarsky 2011-05-05 14:00:37 +0000 Note that if your addon is a Mozilla addon it can already prevent XHR from redirecting. 48091 2 brunoaiss 2011-05-05 16:31:18 +0000 (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. 48092 3 brunoaiss 2011-05-05 16:58:45 +0000 (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 48093 4 bzbarsky 2011-05-05 17:08:07 +0000 In Mozilla, you can just register a redirect observer directly on the underlying nsIChannel. 50137 5 annevk 2011-06-22 22:23:03 +0000 This is for the WebApps WG. 50138 6 annevk 2011-06-22 22:24:50 +0000 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. 63826 7 annevk 2012-02-07 10:43:45 +0000 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. 83323 8 annevk 2013-02-19 14:05:36 +0000 *** Bug 17046 has been marked as a duplicate of this bug. *** 93849 9 cowwoc 2013-09-26 02:24:45 +0000 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? 99609 10 annevk 2014-02-03 11:07:10 +0000 Unfortunately redirects have to be atomic. See bug 24375. 99611 11 julian.reschke 2014-02-03 11:52:39 +0000 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. 99620 12 cowwoc 2014-02-03 17:58:44 +0000 I agree with Julian. This issue should be reopened and the browser should allow the user to read the final URL after redirection completes. 99621 13 annevk 2014-02-03 18:04:50 +0000 That is bug 15417. 99624 14 cowwoc 2014-02-03 18:16:42 +0000 I stand corrected. Thanks Anne.