Bug 3810 – Less common HTTP status codes cause the code to appear as undefined

• Component: DOM
• Status: RESOLVED FIXED

[Henri Sivonen]

Steps to reproduce:
1) Use XMLHttpRequest to POST a document to a server.
2) Have the server respond with HTTP Status 204 No Content or 201 Created.
3) Inspect the status property of the XMLHttpRequest instance upon readyState == 4.

Actual results:
The status property is undefined.

Expected results:
Expected the status code to be exposed to the script like the more common codes.

[Bob Ippolito]

It seems that this happens for a simple GET that returns 200 (as a heisenbug).  Even stranger, the status is 
undefined, but the responseText will be there.

Unfortunately I haven't been able to create a test case, nor can I link to the pages where this happens at 
this time.  Our current workaround is simply to assume 200 if the status was undefined and there is 
responseText.

[Joost de Valk (AlthA)]

A testcase for this would be GREAT. 

[Daniel Udey]

Created attachment 4409 [details]
XMLHttpRequest Status Code Test Case

Here is the HTML for the test case - put this in the same directory as the PHP
file and access via a webserver to test.

[Daniel Udey]

Created attachment 4410 [details]
XMLHttpRequest Status Code Test Case (PHP/HTML)

Here is the test case - extract these files to a web-reachable directory
(requires PHP) and you can test status code responses with it.

You can test this script live at http://sites.darien.ca/temp/php/xmlhttp.html -
this URL should remain active for quite a while (I don't usually delete
things), but it may be faster/more convenient to run locally. This script
supports all the HTTP/1.1 status codes as found in RFC 2616, Section 10, with
one important exception: no 'Location:' header is sent to the browser when an
HTTP code 3xx is sent. This is because Safari will follow the 'Location:'
header to whichever other URL is given, and thus there is no point in
redirecting.

Using this script with the stock Tiger Safari, I can reproduce this bug on
response codes 204 and 205 (intermittently), and all response codes 3xx return
'undefined'.

[Eric Seidel (no email)]

I'm surprised Alexey hasn't been all over this bug. :)

[Alexey Proskuryakov]

With ToT, I cannot reproduce this for 200, 204 or 205 (perhaps, as a side effect of the fix in bug 5924). 
The behavior is still largely different, though.

Basically, it seems that Firefox ignores the meaning of many HTTP statuses here (e.g. it still receives the 
response data for 204 No Content or 304 Not Modified responses). OTOH, NSURLConnection doesn't pass 
the data for 204, and emits an error for 304 - which may be correct.

Are there any cases that should be considered bugs left? Do we need to match Firefox exactly?

[Sen Haerens]

(In reply to comment #6)
> NSURLConnection doesn't pass 
> the data for 204, and emits an error for 304 - which may be correct.

I still think the 304 "not modified" status should be returned. I’m building a dashboard widget that parses static XML files. Upon sending the correct If-None-Match and If-Modified-Since headers the server returns 304 but the XMLHttpRequest status returns undefined so it’s impossible to retrieve the data from cache and save some bandwith.

[Alexey Proskuryakov]

The current version of the Web Applications spec <http://www.whatwg.org/specs/web-apps/current-work/#scripted-http> says that these conditional headers cannot be overridden. In WebKit, it would be the job of NSURLConnection to automatically cache the responses and to send correct conditional headers. When a 304 response is received, NSURLConnection transparently transforms it into a 200 response.

However, WebKit doesn't allow NSURLConnection to do the caching, which is a bug according to the next paragraph of the spec. Assuming the spec isn't about to be changed (it's a draft with many known issues), this is something that needs to be fixed. Since this is a separate issue, please file a new bug on it.

[Eric Seidel (no email)]

7385 is another possible dup.

[Alexey Proskuryakov]

(In reply to comment #7)
The XMLHttpRequest spec has been changed, now it is specified that If-Modified-Since and other conditional headers can be overridden, and such requests should bypass the cache. Fixed in bug 8210. However, this is not directly related to this bug, which deals with unconditional POST requests.

(In reply to comment #6)
I am now seeing a problem with 204 responses: they seem to be handled correctly, but break further requests (which all start to return 204). This is not a WebKit issue; filed as <rdar://4612890>.

Not passing a 304 response for unconditional requests is <rdar://4457674>.

This leaves us with invalid 3xx responses (lacking Location), for which the status is returned as undefined. I am not sure whether this is something that needs to be fixed.

[David Thorpe]

I'm receiving an exception (INVALID_STATE_ERR: DOM Exception 11) when I try to access the XMLHttpRequest.status method on 303 responses where there is a Location: header returned. I have tried PUT and POST methods. Here is my code:

var theRequest = new XMLHttpRequest();
var theContent = [an xml document as a string];
var theURI = [the URI of the web service endpoint];
try {
  theRequest.open("POST",theURI);
  theRequest.setRequestHeader('Content-Type', 'text/xml');
  theRequest.setRequestHeader('X-HTTP-Method-Override', 'PUT');
  theRequest.send(theContent);
  if(theRequest.status == 204 || theRequest.status == 303 || theRequest.status == 200) {
    return theRequest.responseText;        
  }
} catch(theException) {
  alert("Exception caught, " + theException);				
}

I'm using Safari Version 3.0.3 (522.12.1) on OS X Tiger 10.4.10. I believe for AJAX purposes 303 responses should be handled correctly when there is a Location: header returned, at the moment the exception is not very useful. Thanks.

David Thorpe [e-mail]

[Alexey Proskuryakov]

(In reply to comment #11)
> I'm receiving an exception (INVALID_STATE_ERR: DOM Exception 11) when I try to
> access the XMLHttpRequest.status method on 303 responses where there is a
> Location: header returned. 

This is expected behavior: you are making an async request, so theRequest.status and theRequest. responseText are not available right after send(). You need to process the results from an onreadystatechange callback.

I'm going to close this bug - most (or all) issues that were originally reported seem to be fixed by now, and keeping it open just adds to confusion.

[Lucas Forschler]

Mass moving XML DOM bugs to the "DOM" Component.