Bug 10716 – XMLHttpRequest.responseText is null if HTTP response is empty

• Status: RESOLVED
• Resolution: FIXED
• Component: XML

[Daniel Kinzler]

Disclaimer: I don't have Safari around to check for myself, so the below is kind of second hand and the platform is a guess. Also, I originally reported this as a comment to bug 10638, but was told to file it separately.

The Problem: apperently, responseText, status, statusText 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).

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.

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.

Generally, this appears to be needed as a test case:

if ( readyState == 4 )
  assert ( status != null && statusText != null && responseText != null );

Test this especially with an empty response, for "200 OK" and for "304 Not Modified" (for both cases: explicite or implicite If-Modified-Since).

[Mark Rowe (bdash)]

Confirmed with ToT.  The base issue with statusText and status being null on an empty response is covered by bug 5924, and is fixed in ToT.

The responseText problem looks like it was a part of bug 5924 that didn't get fixed.  XMLHttpRequests's m_response is initialized to null in XMLHttpRequest::open.  XMLHttpRequest::receivedData bails out early if the length of data is zero, rather than setting m_response to the empty string as is expected.

[Alexey Proskuryakov]

According to the draft spec (and Firefox), responseText needs to be initialized to an empty string in XHR constructor. WinIE only makes it available in state 4 for empty responses, and throws an exception on earlier access. Either behavior seems logical; I suggest that we go by the spec.

The behavior of responseXML is somewhat different. WinIE initializes it to an empty document in the constructor, and keeps it empty after a parsing error. Firefox, on the other hand, initializes it to null, which conforms to the spec, but puts a descriptive error document on a parsing error (with empty response being an error), which doesn't conform. According to the spec, an error document should be null.

> "304 Not Modified" <...> please check this while you are at it.

See bug 8210.

[Alexey Proskuryakov]

Created attachment 10393 [details]
proposed fix

[Darin Adler]

Comment on attachment 10393 [details]
proposed fix

r=me

[Alexey Proskuryakov]

Committed revision 16226.

re: comments in LayoutTests/ChangeLog - filed bug 10736 for responseXML. The fact the we fail to ever throw exceptions from XHR is prominent enough without additional bugs, I hope to look into it soon.