Closed Bug 337453 Opened 14 years ago Closed 6 years ago
Request doesn't follow 302 redirect if document .domain has been set
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124) Gecko/20060426 Firefox/126.96.36.199 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) Gecko/20060426 Firefox/184.108.40.206 This bug affects pages where you have changed the document.domain to allow access to a different site within your domain e.g. for a page from www.mozilla.org set document.domain to mozilla.org. If you then do an XMLHttpRequest and the response is a 302 moved temporarily redirect then the request returns with a readyState of 4 and status of 302 i.e. the redirect is not automatically followed. If the domain is not changed the redirect is automatically followed and the readyState goes to 4 with a status of 200. For comparison when using IE 6.0 the redirect is automatically followed regardless of the domain setting. Reproducible: Always Steps to Reproduce: 1. document.domain = "yourdomain.com" 2. do XMLHttpRequest to a page on www.yourdomain.com that will return a 302 "moved temporarily" redirect 3. check the status from the response handler when ready state is 4 4. repeat above but don't set the domain first Actual Results: At step 3 status will be 302 => redirect not followed. At step 4 status will be 200 => redirect followed Expected Results: Expect to be the same regardless of domain setting (assuming domain setting was legal) Works in both cases with IE 6.0
Okay, I made a mistake - should have been filed against Mozilla.
Product: Firefox → Mozilla Application Suite
(In reply to comment #0) > If you then do an XMLHttpRequest and the response is a 302 moved temporarily > redirect then the request returns with a readyState of 4 and status of 302 > i.e. the redirect is not automatically followed. "not automatically followed" is applicable to readyState/status value only? i.e. HTTP GET to redirected URI(Location returned with 302) is executed by Mozilla, but readyState is changed to 4(completed. "Loaded" in W3C draft) when 302 is returned, instead of keeping it 1(loading. "Open" in W3C draft) or 2(loaded. "Sent" in W3C draft) or 3(interactive. "Receiving" in W3C draft), and further onreadystatechange will never be scheduled, and status stays 302 forever. Or Mozilla stops at 302, then HTTP GET to the redirected URI is NOT issued? >An explanation of XMLHttpRequest http://www.w3schools.com/xml/xml_http.asp >W3C working draft for XMLHttpRequest http://www.w3.org/TR/XMLHttpRequest/ Confusion of 2=loaded and 4=Loaded in W3C working draft?
Component: General → Networking: HTTP
Product: Mozilla Application Suite → Core
QA Contact: general → networking.http
Version: unspecified → 1.8 Branch
The latter - "Mozilla stops at 302, then HTTP GET to the redirected URI is NOT issued". However what I would expect is that we'd never arrive at this state so as to obey the meaning of "transparently" in W3C spec you referenced: "If the response is an HTTP redirect (status code 301, 302, 303 or 307), then it MUST be transparently followed (unless it violates security or infinite loop precautions)." I don't see any security violation - whereas in Firefox 1.0.x this might have been considered one and prevented the "transparent" following of the reference.
anything in the js console?
Simon Waddington, if this is still an issue, can you please reply to Christian Biesinger's question from comment #4. If this is not still an issue (bug) can you please state so.
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.