Bug 16269 – WebKit fails WICD XMLHttpRequest gzip'd content test

• Component: XML
• Status: RESOLVED WORKSFORME

[Eric Seidel (no email)]

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.

[Mark Rowe (bdash)]

I think the issue here may be that CFNetwork doesn't recognise x-gzip.

[Alexey Proskuryakov]

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.

[Eric Seidel (no email)]

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.

[Eric Seidel (no email)]

I've notified Timur that I believe the test is incorrect as is.

[timur mehrvarz]

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.

[David Kilzer (:ddkilzer)]

(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>

[timur mehrvarz]

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.

[Alexey Proskuryakov]

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.

[timur mehrvarz]

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.

[David Kilzer (:ddkilzer)]

<rdar://problem/5663656>

[Alexey Proskuryakov]

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.

[Alexey Proskuryakov]

Oops, sorry - I tested the bug URL, which is supposed to fail until CFNetwork is changed. The new one works correctly.