WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED DUPLICATE of
bug 58727
50746
[Qt] GZip-Compressed content is not shown if end-of-file marker is missing
https://bugs.webkit.org/show_bug.cgi?id=50746
Summary
[Qt] GZip-Compressed content is not shown if end-of-file marker is missing
Thomas Thrainer
Reported
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.
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
View All
Add attachment
proposed patch, testcase, etc.
Thomas Thrainer
Comment 1
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
).
WebKit Review Bot
Comment 2
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.
Benjamin Poulain
Comment 3
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 :)
Thomas Thrainer
Comment 4
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 :-).
Benjamin Poulain
Comment 5
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.
Robert Hogan
Comment 6
2011-06-20 12:15:13 PDT
*** This bug has been marked as a duplicate of
bug 58727
***
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