Currently WebKitGTK+ is limited to using identity as content encoding. We are unable to take advantage of compression, for faster transfer rates, for instance. See https://bugs.webkit.org/show_bug.cgi?id=25854 and http://bugzilla.gnome.org/show_bug.cgi?id=522772 for more information.
*** Bug 26233 has been marked as a duplicate of this bug. ***
*** Bug 25481 has been marked as a duplicate of this bug. ***
*** Bug 29221 has been marked as a duplicate of this bug. ***
*** Bug 30066 has been marked as a duplicate of this bug. ***
OK, since real Content-Encoding support is probably not coming until GNOME 2.30, and we're continuing to trip over sites that use "Content-Encoding: gzip" even though we send "Accept-Encoding: identity" (notably archive.org), maybe a gross hack is in order... what we'd do is, check from gotHeadersCallback if the response includes "Content-Encoding: gzip"; if so, disconnect from content-sniffed and got-chunk and connect to got-body. Wait until the got-body handler is called, unzip the body data all at once, call soup_content_sniffer_sniff() if necessary, and then belatedly emit all the webkit "signals". This would break incremental rendering of the data, but it would only be getting used on broken sites anyway.
(In reply to comment #5) > OK, since real Content-Encoding support is probably not coming until GNOME > 2.30, and we're continuing to trip over sites that use "Content-Encoding: gzip" > even though we send "Accept-Encoding: identity" (notably archive.org), maybe a > gross hack is in order... what we'd do is, check from gotHeadersCallback if the > response includes "Content-Encoding: gzip"; if so, disconnect from > content-sniffed and got-chunk and connect to got-body. Wait until the got-body > handler is called, unzip the body data all at once, call > soup_content_sniffer_sniff() if necessary, and then belatedly emit all the > webkit "signals". This would break incremental rendering of the data, but it > would only be getting used on broken sites anyway. I have been thinking the same. Are you planning to write such a patch, or should I try to secure some time to get it done?
i was not planning to write it myself
ok, i'm working on avb's update of my original patches. see the linked b.g.o bug
*** Bug 30934 has been marked as a duplicate of this bug. ***
I just wanted to let you know in case you didn't see it in the gnome bug posted in the first message that support for proper content encoding should be released soon with libsoup-2.28.2. There is also a patch there that supposedly enables these features for webkit.
*** Bug 31982 has been marked as a duplicate of this bug. ***
Created attachment 44968 [details] patch to use SoupContentDecoder (note that while this claims to require libsoup >= 2.28.2, i haven't actually updated the gnome-2-28 branch yet, so you'll want to test against master. that will be fixed before this gets committed of course.)
style-queue ran check-webkit-style on attachment 44968 [details] without any errors.
(In reply to comment #12) > Created an attachment (id=44968) [details] > patch to use SoupContentDecoder > > (note that while this claims to require libsoup >= 2.28.2, i haven't actually > updated the gnome-2-28 branch yet, so you'll want to test against master. that > will be fixed before this gets committed of course.) The patch needs an #ifdef SOUP_TYPE_CONTENT_DECODER because otherwise it fails with current releases.
Comment on attachment 44968 [details] patch to use SoupContentDecoder Thanks!
(In reply to comment #14) > The patch needs an #ifdef SOUP_TYPE_CONTENT_DECODER because otherwise it fails > with current releases. We decided to not handle this, and assume people mostly know what they're doing when using development releases. 2.29.4 will have it.
Comment on attachment 44968 [details] patch to use SoupContentDecoder Clearing flags on attachment: 44968 Committed r52208: <http://trac.webkit.org/changeset/52208>
All reviewed patches have been landed. Closing bug.
*** Bug 29768 has been marked as a duplicate of this bug. ***