XMLHttpRequest::responseMIMEType() gets its result from response headers, but those are not available for non-HTTP requests. It should ask ResourceResponse instead.
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.
Created attachment 15206 [details]
-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?
(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).
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.
Comment on attachment 15206 [details]
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.
(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.
Created attachment 15249 [details]
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!
Comment on attachment 15249 [details]
I believe this patch addresses all the comments above.
Committed revision 23815.