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 Likes
For reference purposes both of the following JavaScript errors relate to this:
Uncaught ReferenceError: bmi_load is not definedUncaught ReferenceError: bmi_SafeAddOnload is not defined
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 Like
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.
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.
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.