Avoid meta-refresh when back-button gets non-sdch content

The first page search from google will not be SDCH encoded, but will
trigger a background download of a dictionary for future use.
..but..
IF the user navigates forward from the search page, and then back, then
Chromium will fetch the content from cache after specifying in the URL
that a dictionary is now available.   This new logic detects such a
situation where non-SDCH content is pulled from the cache, and avoids
the (slower and overly conservative) meta-refresh.

test=see bug for repro cases.  Check about:histogram/SDCH for error codes.
bug=20457
r=kmixter
Review URL: http://codereview.chromium.org/518016

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35318 0039d316-1c4b-4281-b951-d872f2087c98

2 files changed, 16 insertions, 5 deletions

diff --git a/net/base/sdch_filter.cc b/net/base/sdch_filter.cc
index 8a21ed7..1687226 100644
--- a/net/base/sdch_filter.cc
+++ b/net/base/sdch_filter.cc
@@ -160,14 +160,21 @@ Filter::FilterStatus SdchFilter::ReadFilteredData(char* dest_buffer,
       // Watch out for an error page inserted by the proxy as part of a 40x
       // error response.  When we see such content molestation, we certainly
       // need to fall into the meta-refresh case.
-      bool successful_response = filter_context().GetResponseCode() == 200;
       if (filter_context().GetResponseCode() == 404) {
         // We could be more generous, but for now, only a "NOT FOUND" code will
-        // cause a pass through.  All other codes will fall into a meta-refresh
-        // attempt.
+        // cause a pass through.  All other bad codes will fall into a
+        // meta-refresh.
         SdchManager::SdchErrorRecovery(SdchManager::PASS_THROUGH_404_CODE);
         decoding_status_ = PASS_THROUGH;
-      } else if (possible_pass_through_ && successful_response) {
+      } else if (filter_context().GetResponseCode() != 200) {
+        // We need to meta-refresh, with SDCH disabled.
+      } else if (filter_context().IsCachedContent()
+                 && !dictionary_hash_is_plausible_) {
+        // We must have hit the back button, and gotten content that was fetched
+        // before we *really* advertised SDCH and a dictionary.
+        SdchManager::SdchErrorRecovery(SdchManager::PASS_THROUGH_OLD_CACHED);
+        decoding_status_ = PASS_THROUGH;
+      } else if (possible_pass_through_) {
         // This is the potentially most graceful response. There really was no
         // error. We were just overly cautious when we added a TENTATIVE_SDCH.
         // We added the sdch coding tag, and it should not have been added.
@@ -182,7 +189,7 @@ Filter::FilterStatus SdchFilter::ReadFilteredData(char* dest_buffer,
         // the meta-refresh result.
         // TODO(jar): Improve robustness by sniffing for valid text that we can
         // actual use re: decoding_status_ = PASS_THROUGH;
-      } else if (successful_response && !dictionary_hash_is_plausible_) {
+      } else if (!dictionary_hash_is_plausible_) {
         // One of the first 9 bytes precluded consideration as a hash.
         // This can't be an SDCH payload, even though the server said it was.
         // This is a major error, as the server or proxy tagged this SDCH even
diff --git a/net/base/sdch_manager.h b/net/base/sdch_manager.h
index b5f9500..e6286f5 100644
--- a/net/base/sdch_manager.h
+++ b/net/base/sdch_manager.h
@@ -124,6 +124,10 @@ class SdchManager {
     INCOMPLETE_SDCH_CONTENT = 77,   // Last window was not completely decoded.
     PASS_THROUGH_404_CODE = 78,     // URL not found message passing through.
 
+    // This next report is very common, and not really an error scenario, but
+    // it exercises the error recovery logic.
+    PASS_THROUGH_OLD_CACHED = 79,   // Back button got pre-SDCH cached content.
+
     // Common decoded recovery methods.
     META_REFRESH_CACHED_RECOVERY = 80,  // Probably startup tab loading.
     DISCARD_TENTATIVE_SDCH = 81,        // Server decided not to use sdch.