summaryrefslogtreecommitdiffstats
path: root/net/base/sdch_manager.h
diff options
context:
space:
mode:
authorjar@chromium.org <jar@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2009-06-22 19:26:28 +0000
committerjar@chromium.org <jar@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2009-06-22 19:26:28 +0000
commita358604cd69a2b88be50b7055e377f97014b9ca2 (patch)
tree6f4da365353e1fdc89639b3ed600e8b258b77a82 /net/base/sdch_manager.h
parentc459c351504a1c124697b5a7e77d275c09047de0 (diff)
downloadchromium_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.h2
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.