Chromium has to deal with a lot of problematic proxies, and this is probably
what drove the "feature" that you've noticed. If the problem is as I
expect, there is now a nice work-around that your proxy can use to avoid the
issue (see below).
To be fair, Chromium doesn't completely "shut off" SDCH, but rather starts
an exponential backoff of using SDCH for the specific site that has violated
certain restrictions. Most of the time, Chromium just tries to gracefully
recover from corruption caused by problematic proxies. For example, some
proxies will discard the content-encoding "sdch,gzip" string, re-gzip-ing
the content, and then re-writing thecontent-encoding as simply "gzip."
Pleasantly enough, Chromium can detect this corruption, and silently repair
it :-). When the corruption appears to be too great, then Chromium will
reload the page (relatively transparently to the user) with SDCH disabled,
and will perform the exponential blacklist-back-off I mentioned.
The most problematic errors can't be "repaired." The one that caused me to
lose the most sleep was a proxy that allowed almost all phases of a valid
SDCH request to proceed. It allowed the browser to be notified of
the existence of an SDCH dictionary; allowed the dictionary to be
downloaded, allowed the request with a valid dictionary to be provided, and
THEN it discarded the HTML result, replaced it with a simple error page
(saying something like "unrecognized content. Please don't visit this
site.") and didn't even return an error code <doh!>. To the browser, this
looked like a perfectly reasonable response for a web page request... but it
meant that content from said site could not be obtained by this user :-(.
As a result of this clever proxy, we were forced to assume that IF a site
advertised a dictionary, but didn't use it in the response, then it was
possibly this evil proxy.... and we needed to back off.
For Chromium, I recently landed a "work-around" that a server can use if it
only sometimes wishes to employ SDCH. Note that due to the above feature,
intermittent use of SDCH will look like intermittent proxy corruption :-/.
If an SDCH server wants to (safely) return non-SDCH encoded content, despite
having advertised a dictionary, it needs to add the HTTP header:
X-Sdch-Encode: 0
That header will alert the browser that it was an intentional (server
side) omission of SDCH compression, and no defensive measures are needed.
You can also read about the bug in
http://code.google.com/p/chromium/issues/detail?id=78489
The code landed in mid-May, and is probably part of at least the Dev channel
for Chrome by now (perhaps even beta). Chrome is VERY effective at updating
its user base, and so it should be on the order of a week or two from when
this hits the STABLE channel before a very large percentage of Chrome users
have auto-updated.
I hope this can help,
Jim
