SDCH and Chrome

[Gregor]

Hi We have built an SDCH proxy server are in the process of testing.
We are having some issues we are trying to debug but have a problem
with Chrome “locking us out” ie

If Chrome gets some SDCH is does not like it seem to switch it off
completely? Does anyone know if there is a way to stop this from
happening?

Thanks
Greg

[Jim R]

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