WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED WORKSFORME
16269
WebKit fails WICD XMLHttpRequest gzip'd content test
https://bugs.webkit.org/show_bug.cgi?id=16269
Summary
WebKit fails WICD XMLHttpRequest gzip'd content test
Eric Seidel (no email)
Reported
2007-12-03 03:27:47 PST
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.
Attachments
Add attachment
proposed patch, testcase, etc.
Mark Rowe (bdash)
Comment 1
2007-12-03 05:26:57 PST
I think the issue here may be that CFNetwork doesn't recognise x-gzip.
Alexey Proskuryakov
Comment 2
2007-12-08 08:12:50 PST
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)
Comment 3
2007-12-18 14:47:02 PST
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)
Comment 4
2007-12-18 14:47:23 PST
I've notified Timur that I believe the test is incorrect as is.
timur mehrvarz
Comment 5
2007-12-18 15:02:03 PST
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)
Comment 6
2007-12-18 22:14:38 PST
(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
Comment 7
2007-12-26 00:59:21 PST
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
Comment 8
2007-12-26 01:41:47 PST
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
Comment 9
2007-12-26 06:00:12 PST
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)
Comment 10
2007-12-26 21:03:34 PST
<
rdar://problem/5663656
>
Alexey Proskuryakov
Comment 11
2010-04-27 13:37:07 PDT
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
Comment 12
2010-04-27 13:38:11 PDT
Oops, sorry - I tested the bug URL, which is supposed to fail until CFNetwork is changed. The new one works correctly.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug