Bug 14288 – REGRESSION: XMLHttpRequest doesn't use a correct content type for file:// URLs

• Component: XML
• Status: RESOLVED FIXED

[Alexey Proskuryakov]

XMLHttpRequest::responseMIMEType() gets its result from response headers, but those are not available for non-HTTP requests. It should ask ResourceResponse instead.

[Alexey Proskuryakov]

This is a regression in a way: since shipping Safari/WebKit blindly used an HTML/XML parser for all responses, it didn't care whether the request was an HTTP one.

[Alexey Proskuryakov]

Created attachment 15206 [details]
proposed fix

[Mark Rowe (bdash)]

-PASS -- testing: foo,bar/baz+xml -- responseXML: null
+FAIL (got document -- response type: foo,bar/baz+xml) -- testing: foo,bar/baz+xml -- responseXML: [object Document]

Your change adds this FAIL line, which doesn't look right.  Is that expected?

[Alexey Proskuryakov]

(In reply to comment #3)
> Your change adds this FAIL line, which doesn't look right.  Is that expected?

Yes, as I mentioned in the ChangeLog, this is an edge case resulting from different Content-Type parsing (I suppose this particular failure can be qualified as an NSURLConnection bug, but I haven't investigated it enough to file a bug).

FAIL lines in expected results are seriously confusing. Since WebKit tests are regression tests, it is best, in my opinion, to design the test so that it does not say FAIL (a comment about how current behavior is incorrect can be added).

[Alexey Proskuryakov]

Personally, I do not have a problem with a failing test saying that it fails - especially when it verifies a large set of cases.

Anyway, it's not a new issue with this test, as it already had FAIL lines.

[Maciej Stachowiak]

Comment on attachment 15206 [details]
proposed fix

This patch looks ok to me as is. However, maybe it would be better to parse Content-Type ourselves for http, but trust the network layer for other protocols. In particular, we might want to avoid the network layer's possible content-based sniffing for XHMLHttpRequest.

The patch is fine as is however.

[Alexey Proskuryakov]

(In reply to comment #7)
> In particular, we might want to avoid the network layer's possible
> content-based sniffing for XHMLHttpRequest.

Agreed; I'm going to test this in other browsers.

[Alexey Proskuryakov]

Created attachment 15249 [details]
proposed fix

OK, testing sniffing in other browsers doesn't make all that much sense, since they don't honor HTML metas anyway. But getting HTTP content sniffing out of the equation for XHR is definitely nice!

[Geoffrey Garen]

Comment on attachment 15249 [details]
proposed fix

r=me

I believe this patch addresses all the comments above.

[Alexey Proskuryakov]

Committed revision 23815.