Bug 76074
| Summary: | Gzip content is not decoded before fully received | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Ligius <ligius> |
| Component: | Page Loading | Assignee: | Nobody <webkit-unassigned> |
| Status: | UNCONFIRMED | ||
| Severity: | Normal | CC: | ap, jeffreyko3-c, mnot |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
Ligius
We are trying to create a server push solution by keeping a socket open and pushing json objects through it. Unfortunately on Webkit (both Chrome and Safari that is) the content is not decoded if the encoding is set to gzip.
Request URL:http://localhost:8888/*****
Request Method:GET
Status Code:200 OK
Request Headers
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8,ro;q=0.6,de-DE;q=0.4,de;q=0.2
Connection:keep-alive
Cookie:JSESSIONID=1144msirlwv5kawm1mnr3f1k0
Host:localhost:8888
Referer:http://localhost:8888/**************
User-Agent:Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.75 Safari/535.7
Response Headers
Cache-Control:no-cache
Content-Encoding:gzip
Content-Type:text/html
Expires:0
Server:Jetty(7.4.0.v20110414)
Transfer-Encoding:chunked
If the gzip encoding is removed the browser behaves as expected, parsing the data in real-time. If the content is gzipped then although the Size/Content column inside "Developer Tools" gets updated, no data is visible in the preview or response tabs, until the stream is stopped.
We rely on keeping connection open until webkit is implemented by all browsers. We also rely on the gzip compression since the pushed data can get quite big and with this we get about 1:20 compression.
IE8 and FF8 work as expected with this and no errors are displayed in the javacript console. If I output the stream to a file I can gunzip it correctly until it complains about unexpected EOF, but everything is decoded correctly.
I can provide additional details if needed but I cannot provide any code for reproduction, although I suppose it is not needed in this case. Might be that it has to do with some specs inside the RFC for content-encoding that specifies gzip can only be decompressed after all chunks have been received.
I cannot see any other way of streaming endless data to a client without using WebSocket.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Ligius
The stream is being decoded on-the-fly since I see both the compressed and uncompressed size in the Network Developer Tools tab.
Alexey Proskuryakov
This would be difficult to investigate without a live Web site to test on.