Add `Cache-Control "no-transform"` HTTP header

Contribute Feature

AI-generated summary

A discussion is ongoing about adding the Cache-Control "no-transform" HTTP header to prevent HTML content modification and JavaScript errors when accessing Discourse sites via certain mobile networks. DeanMarkTaylor suggests that this header would resolve the issue and recommends also adding it to JavaScript files. However, codinghorror thinks that this solution is not foolproof, as some proxies might not respect the header, and instead proposes focusing on HTTPS as a more reliable solution.

DeanMarkTaylor counters that some mobile networks, like Vodafone, do respect the no-transform header and that it is mandated by the HTTP spec. codinghorror does not object to adding the header, but notes that it may not address issues with CloudFlare sites. DeanMarkTaylor clarifies that he never suggested the header would solve problems with CloudFlare sites, but rather that it may impact other reverse proxies and optimization services.

1

Continuing the discussion from JavaScript Uncaught ReferenceError: bmi_load is not defined:

Accessing a Discourse site via UK 3G/GPRS providers causes HTML content to be modified and JavaScript errors to be introduced.

Adding Cache-Control "no-transform" header for HTML results would resolve this.

However this might have other ramifications in terms of intermediate caching servers, but as long as this isn’t included on the image files it shouldn’t have that much of an effect other than preventing JavaScript errors.

If a site is behind Google PageSpeed - this header would cause the page not to be rewritten, perhaps impacting CloudFlare sites too… personally I would prefer knowing the site is loaded without errors.

Personally I have experienced this before non-discourse sites where Google Maps wouldn’t load because the HTML was modified (corrupting valid HTML) and the JavaScript for Google Maps then being unable to read the “key” required in the .js file URL.

Considering .js files are highly optimised by Disourse I would also recommend adding the “no-transform”` HTTP header JavaScript files too, there is no need for them to be modified (“transformed”).

2 лайка
Nil usage errors in un-self-deleting posts
2

For reference purposes both of the following JavaScript errors relate to this:

  • Uncaught ReferenceError: bmi_load is not defined
  • Uncaught ReferenceError: bmi_SafeAddOnload is not defined
3

I see this as a problem that is irreconcilable. Just because you add a header does not mean it will be respected, and the kind of folks who are willing to do ethically bizarre stuff like modify the page in flight are not likely to be stopped by saying please in the headers.

Better to focus on https which cannot be modified in flight this is the correct technical solution, not this kind of sporadically supported “say please” band aid.

1 лайк
4

In Vodafone the 2nd largest UK mobile network carrier (in terms of revenue) does indeed modify the page to include the failing JavaScript and also does respect the no-transform header.

Actually a Vodafone employee wrote the initial draft and was an editor for the W3C Content Transformation Landscape Working Group Note in 2007 which outlines Content Transformation proxies handling things like this.

And obviously the HTTP spec mandates how a proxy server MUST handle the no-transform header.

Sadly this is not “ethically bizarre” this is “normal” and within spec except for where a no-transform header is included, then a proxy “MUST NOT” transform the data.

5

A quick Google search does not confirm that this setting would address any of the CloudFlare issues. However if we already have the header e.g.

Cache-Control: private, no-store, no-cache, must-revalidate, no-transform, max-age=0

I do not object to adding that bit on.

6

It was never my thought that it would solve problems with CloudFlare sites, I was actually covering the point that this change may impact on other reverse / transparent proxies / optimisation services in ways specific them.