On 17.12.2008, at 11:47, Tom Hume wrote:

There are efforts ongoing to put pressure on ISPs to either drop
transcoding altogether, or at least configure it responsibly. I'd be
interested in hearing any thoughts on technical solutions to this
problem; would it, for instance, be reasonable and/or pragmatically
defensive to include "Cache-control: no-transform" by default on HTTP
requests triggered by AJAX clients or servers?


We're sending this header currently on a large German site - unfortunately, I've not encountered/heard of a transforming proxy yet which actually respects this header (on the other hand, a proxy which is coded carefully enough to actually respect the header would usually also be coded carefully enough not to include any bugs in the transformation, that's probably why I never encountered a proxy where the header did actually help to circumvent a problem).

This issue is worse than it appears on first sight, because many transforming proxies are actually buggy and cause errors in JavaScript code, not only in AJAX data requests. So far I've only once managed to get a mobile carrier to actually fix his bugs.

Common problems are, that some of them truncate or remove parts of JavaScript files if they contain strings like "</" or // - even in a string/regexp! These are obviously oversimplified, regexp-based buggy comment filters at work.

That's the reason why we for example use a locally patched version of jQuery where all occurrences of // and </ in strings are hidden from those proxies by using <\/ and \/\/ instead, which usually goes through. I submitted a jQuery feature request months ago where I requested whether anti-transforming-proxy changes like this could be done in the official version of jQuery so I need not always patch it myself, unfortunately it has been ignored so far.

--
Markus Peter - w...@spin.de - http://www.spin-ag.de/ - http://www.spin.de/
SPiN AG, Bischof-von-Henle-Str. 2b, 93051 Regensburg, HRB 6295 Regensburg Aufsichtsratsvors.: Dr. Christian Kirnberger, Vorstände: F. Rott, P. Schmid



Reply via email to