Bug 50746 - [Qt] GZip-Compressed content is not shown if end-of-file marker is missing
Summary: [Qt] GZip-Compressed content is not shown if end-of-file marker is missing
Status: RESOLVED DUPLICATE of bug 58727
Alias: None
Product: WebKit
Classification: Unclassified
Component: Page Loading (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Linux
: P2 Normal
Assignee: Nobody
URL:
Keywords: Qt, QtTriaged
Depends on:
Blocks:
 
Reported: 2010-12-09 03:14 PST by Thomas Thrainer
Modified: 2011-06-20 12:15 PDT (History)
7 users (show)

See Also:


Attachments
Ignore HttpError when the HTTP status code is 200 and at least some data was received (509 bytes, patch)
2010-12-09 03:14 PST, Thomas Thrainer
benjamin: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Thrainer 2010-12-09 03:14:30 PST
Created attachment 76036 [details]
Ignore HttpError when the HTTP status code is 200 and at least some data was received

Seen on the german eBay site, when logging into "Mein eBay".

The Problem is that the gzip-stream sent by the server is correct, but does not have an end-of-file marker (zcat says "unexpected end of file"). Other browsers (Chrome, Firefox) do load the page without any error messages.
 
I attach a patch which fixes this problem, and does show all available content when the server has sent a status code of 200. Potentially, incomplete pages could be shown with this patch. I don't think that's an issue tough, because otherwise the QWebPage's error page is shown instead of any data.
Comment 1 Thomas Thrainer 2010-12-10 01:24:53 PST
I just realized that patching QtWebKit alone is probably not enough.

In Qt, qhttpnetworkconnectionchannel.cpp (what a mouth full!), in the expand(...) method around line 585, QHttpNetworkReplyPrivate::gunzipBodyPartially(...) is called. The return value is compared to Z_STREAM_END if the received data was complete, which fails as the end-of-stream marker is missing. The decompressed data is _not_ appended to the received data in this case, instead an error is emited. This will cause the last piece of data to be lost.

The right thing to do would probably be to append the data if it was successfully received (i.e. ret >= Z_OK), emit readyRead and dataReadProgress anyways, and only finally emit an error if dataComplete && ret != Z_STREAM_END.

But I think somebody more knowledgeable than me should have a look at this and decide what's best to do. For now, QtWebKit does handle the eBay-site happily with the attached patch, even if some bytes are probably missing at the end.

I created a Qt-bug for this issue too (http://bugreports.qt.nokia.com/browse/QTBUG-16022).
Comment 2 WebKit Review Bot 2011-01-16 23:43:22 PST
Attachment 76036 [details] did not pass style-queue:

Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files']" exit_code: 1

Total errors found: 0 in 0 files


If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 3 Benjamin Poulain 2011-03-02 14:18:52 PST
Comment on attachment 76036 [details]
Ignore HttpError when the HTTP status code is 200 and at least some data was received

This is a bad idea. If a page has status 200, and the network is disconnected in the middle of the load, the frame will report loadFinished as if everything was find.

And this patch is without test and changelog :)
Comment 4 Thomas Thrainer 2011-03-02 23:35:02 PST
Actually, this patch was not really meant to be included, but rather as illustration for the problem and a (possible) solution for it. I don't think that I have enough knowledge about the WebKit codebase such that I can really propose a real solution for the problem...

I guess I have misunderstood the patch submission and review process in this bugzilla tough :-).
Comment 5 Benjamin Poulain 2011-03-03 02:23:56 PST
(In reply to comment #4)
> I guess I have misunderstood the patch submission and review process in this bugzilla tough :-).

Ok, no problem.
You had set the r? flags, this request review for landing the patch in WebKit.
Comment 6 Robert Hogan 2011-06-20 12:15:13 PDT

*** This bug has been marked as a duplicate of bug 58727 ***