diff options
author | jar@chromium.org <jar@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-06-22 19:26:28 +0000 |
---|---|---|
committer | jar@chromium.org <jar@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-06-22 19:26:28 +0000 |
commit | a358604cd69a2b88be50b7055e377f97014b9ca2 (patch) | |
tree | 6f4da365353e1fdc89639b3ed600e8b258b77a82 /net/base/sdch_manager.h | |
parent | c459c351504a1c124697b5a7e77d275c09047de0 (diff) | |
download | chromium_src-a358604cd69a2b88be50b7055e377f97014b9ca2.zip chromium_src-a358604cd69a2b88be50b7055e377f97014b9ca2.tar.gz chromium_src-a358604cd69a2b88be50b7055e377f97014b9ca2.tar.bz2 |
Handle proxy corruption including nesting of compressino algorithms
Vodaphone (UK) Mobile Broadband appears to be providing an extra level
of gzip compression, at the same time as it discards the content encoding
"sdch,gzip" and replaces it with "gzip."
The previous approach for handling a missing "sdch" content encoding
statement from a server that *probably* was trying to send encoded
content, was to replace the (probably) garbage content encoding with
tentative decodings for both gzip and sdch. That approach was not
sufficient for the resulting double-gzip encoding that Vodaphone
provided :-(.
This fix leaves the existing content encodings (such as Vodaphone's
solo "gzip"), and adds the tentative decodings (gzip plus sdch).
Hence we translate received content encodings (when we know we requested
an SDCH response by including an applicable dictionary) as follows:
"sdch,gzip" unchanged. This is perfect.
"" ==> "Tent_sdch, Tent_gzip"
"gzip" ==> "Tent_sdch, Test_gzip, gzip"
Note that the TENTATIVE_gzip is a sniffing gzip, that can turn into an
identity (no-op) filter if it can't find a gzip header.
By continuing to use a tentative SDCH, it is possible for the SDCH
filter to make error recovery decision, and to record stats
on this case.
In addition, I've changed the error recovery approach in the SDCH
filter to be ultra conservative. If there is ANY unrecoverable
error in a response to an SDCH request, then we will blacklist
the host of the URL. Recoverable errors are where the SDCH is fully
functional, and decodes its data using the dictionary.
The test cases added focus on the double gzip cases, as observed in
Vodaphone (UK) Mobile Broadband.
BUG=13606
r=huanr
Review URL: http://codereview.chromium.org/140037
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18936 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'net/base/sdch_manager.h')
-rw-r--r-- | net/base/sdch_manager.h | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/net/base/sdch_manager.h b/net/base/sdch_manager.h index a6c7a3b..c95b890 100644 --- a/net/base/sdch_manager.h +++ b/net/base/sdch_manager.h @@ -122,7 +122,7 @@ class SdchManager { CACHED_META_REFRESH_UNSUPPORTED = 75, // As above, but pulled from cache. PASSING_THROUGH_NON_SDCH = 76, // Non-html tagged as sdch but malformed. INCOMPLETE_SDCH_CONTENT = 77, // Last window was not completely decoded. - + PASS_THROUGH_404_CODE = 78, // URL not found message passing through. // Common decoded recovery methods. META_REFRESH_CACHED_RECOVERY = 80, // Probably startup tab loading. |