Bug 10638 – XMLHttpRequest on Windows doesn't give correct status

• Component: Page Loading
• Status: RESOLVED FIXED

[Karthik Kumar]

When an XMLHTTPRequest object's readyState is 4, it doesn't give me the correct server status (request.status element).. It is null instead of a value like 200, 301 or something. 

sample code to test: (tested in Firefox/Opera/IE)

     function processResponse(httprequest){
 	 var response=null;
  	 if(httprequest==null) return response;
	 if(httprequest.readyState>0&&httprequest.readyState<4){
		showAjax();
	 }
	 else if(httprequest.readyState==4) {
   		hideAjax();
		if(httprequest.status == 200) {
			var responsewrapper=getJSONObject(httprequest.responseText);
			authenticated=false;
			if(responsewrapper!=null) 
				response=responsewrapper.response;
			if(response!=null) {
					authenticateResponse(response);
					errorResponse(response);	
					return response;
			} 	
			showStatus(STATUS_ERROR, "JSON Error: Couldn't read response.");
		}
		else 
			showStatus(STATUS_ERROR, "AJAX Error: Server HTTP status: "+httprequest.status); //Note this: XXXX
	}
	return response;
    } 


//XXXX:	throws: AJAX Error: Server HTTP tatus: [undefined] in Swift

the callback to XMLHTTPRequest is: 

...
var httprequest=makeHTTPRequest(); //returns object successful
httprequest.onreadystatechange=function (){ processResponse(httprequest); }

...

httprequest.open("GET", url, true); //Last parameter is true.

[Daniel Kinzler]

I can confirm that this appears to be a problem for some people (I don't have Safari around to check for myself, so the below is second hand). This bug hits safari users when using an extension i recently contributed to wikipedia - see <http://bugzilla.wikimedia.org/show_bug.cgi?id=7219>. Note that I will try to write a workaround, so it may not be possible to reproduce the problem on wikipedia.

The Problem: apperently, status, statusText, responseText and maybe other fields are null if the response from the server was empty. But empty content is valid in HTTP - so responseText should be an empty string, and status and statusText should represent what the server actually sent (200 OK, hopefully).

I have seen reports of the same problem showing up if the server responds with "304 Not Modified" (see <http://www.bitterpill.org/bp/2005-06/safari-xmlhttprequest-undefine.html>) - please check this while you are at it. As per the w3c draft, 304s should be handeled transparently by XMLHttpRequest (as 200 OK), unless If-Modified-Since was sent explicitely using setRequestHeader, in which case the actual response (with code 304) should be passed on the to JS code.

[Daniel Kinzler]

I have been told to file the above comment as a separate issue, see <http://bugzilla.opendarwin.org/show_bug.cgi?id=10716>.

[Alexey Proskuryakov]

I think this should be fixed in Safari 3 beta for Windows.