User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008032605 Minefield/3.0b5pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008032605 Minefield/3.0b5pre In nsHttpResponseHead::ParseStatusLine, the following: 188 if (!(line = PL_strchr(line, ' '))) { 189 LOG(("mal-formed response status line; assuming statusText = 'OK'\n")); 190 mStatusText.AssignLiteral("OK"); results in 'OK' being loaded in the XMLHttpRequest object's statusText when the http response per RFC 2616 Section 6: http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html for: Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF includes the HTTP-Version and Status-Code but not a Reason-Phrase. This can happen with some server configurations or error handling in server-side scripts, such that often the Status-Code loaded into status is not 200 and thus 'OK' is an inappropriate value to have loaded artificially into statusText. Also, no entry is generated in the Error Console concerning the missing Reason-Phrase, and so in this regard there is no "tip-off" about the missing Reason-Phrase as the basis for an inappropriate loading of 'OK' when a status is not 200. 6.1.1 states that "The Status-Code is intended for use by automata and the Reason-Phrase is intended for the human user. The client is not required to examine or display the Reason-Phrase." Accordingly, AJAX utilities typically ignore the responseText when status is 200, and otherwise MAY use it in conjunction with status in an alert to inform the human user about an error. Thus, if nsHttpResponseHead::ParseStatusLine does not do a look-up for an appropriate Reason-Phrase when one has not been transmitted, it would be preferable to add a conditional such that 'OK' is loaded into statusText only for 200, and otherwise leave it as the null string. It would also be desirable to add some error handling which is at least sufficient to generate an entry in the Error Console about the missing Reason-Phrase. Reproducible: Always Steps to Reproduce: 1.Arrange for an HTTP request to return a response which indicates the HTTP version and a status code for an error but not an associated reason string. 2. 3. Actual Results: The reason string always is set to 'OK' and no error is indicated. Expected Results: Treating of the associated reason as the null string and at least some indication via the Error Console that the reason string was missing in the response. This is a spin-off from Bug 424875

I don't think we want to change this code. This server is sending a malformed HTTP response; we're just recovering from that. Since the status text is not really standardized, by the way, anyone depending on it is just asking for trouble. In any case, this is the wrong component for changing Mozilla's HTTP implementation in general.

I don't think we want to change this either.