WebKit fails WICD XMLHttpRequest gzip'd content test http://www.w3.org/2004/CDF/TestSuite/WICD_CDR_WP1/test-encoding-gzip.xhtml Not sure why. They seem to be sending the content with the proper headers: HackTop [35683:WebKit]% curl -I "http://www.w3.org/2004/CDF/TestSuite/WICD_CDR_WP1/test-encoding-gzip.txt.tgz" HTTP/1.1 200 OK Date: Mon, 03 Dec 2007 11:25:29 GMT Server: Apache/2 Last-Modified: Wed, 14 Nov 2007 15:03:40 GMT ETag: "43ee4dee72b00" Accept-Ranges: bytes Content-Length: 155 Cache-Control: max-age=21600 Expires: Mon, 03 Dec 2007 17:25:29 GMT P3P: policyref="http://www.w3.org/2001/05/P3P/p3p.xml" Content-Type: text/plain Content-Encoding: x-gzip I don't think this is an SVG-specific issue.
I think the issue here may be that CFNetwork doesn't recognise x-gzip.
I think that this test is not correct - the server sends "Content-Encoding: x-gzip" even though we didn't ask for it in Accept-Encoding. CFNetwork does support "gzip" content encoding, as specified in RFC 2616. Support for "x-gzip" is not a MUST-level requirement, so it is conforming to omit it even when "gzip" is supported.
Ok, well, I think regardless we should encourage CFNetwork to support the x-gzip type. This bug should be moved to Radar and then closed.
I've notified Timur that I believe the test is incorrect as is.
The x-gzip header: it's an issue with the w3.org servers. They should just send "gzip": http://lists.w3.org/Archives/Public/public-cdf/2007Dec/0002.html I am waiting for a solution and will update you here. Other than the Content-Encoding, that comes from the server, I assume the test itself is OK. Please don't close this just yet.
(In reply to comment #3) > Ok, well, I think regardless we should encourage CFNetwork to support the > x-gzip type. This bug should be moved to Radar and then closed. See Bug 9521. <rdar://problem/5418646>
The w3.org server configuration has been modified, so that Content-Encoding: gzip is now being returned in all cases (instead of x-gzip). However Safari/WebKit still does not decode the text file.
The headers are a bit weird still - I think they trigger a CFNetwork heuristic for misconfigured servers, and it decides that the file is supposed to be downloaded as is, not decoded and displayed. Namely, 1. The file has a .tgz extension. 2. Its Content-Type is text/plain. 3. Its Content-Encoding is gzip. (1) and (2) look highly improbable in combination. So, while this test is now formally valid, it still pushes the limits a bit. OTOH, it's clearly a bug that CFNetwork's heuristic for main resources is enabled for XMLHttpRequest responses (and for subresources, see bug 10409, bug 9521). We need a way to suppress this CFNetwork heuristic.
It's working now. I created a new copy of the gziped txt document, but this time, I have named it "test-encoding-gzip.gz.txt". Also, I am using it from a new test parent document, which is called "test-encoding-gzip2.xhtml". This is now the official, referenced test, the one that you get, when you start from the index. http://www.w3.org/2004/CDF/TestSuite/WICD_CDR_WP1/wicdcore.xhtml#core55 This way, I can turn it green now in our implementation matrix - and, in case you want to take a look at the CFNetwork's heuristic, the old URL's still exist and does show the issue still. Thank you.
<rdar://problem/5663656>
The test fails for me with Safari 4.0.5 on Mac OS X 10.5.8. I thought it was supposed to pass now.
Oops, sorry - I tested the bug URL, which is supposed to fail until CFNetwork is changed. The new one works correctly.