I have encountered a similar problem with JS injection. There are HTTP proxy servers that inject JavaScript into HTML and JS documents ... I believe the purpose of the injected snippets is to examine the DOM and/or the JS code to try and squelch malicious behavior.
The problem is that this particular proxy observes the MIME type in the content-type header very strictly when deciding to inject raw JS or JS bounded by HTML "script" and "/script" tags.
I've found that a number of sites return a content-type of "text/html" for pure JS documents ... documents often referred to in HTML documents via "script src=xxx". The appliance then injects the HTML "script" tags into the raw JS document, breaking the legal JS code.
This causes the JS runtime to halt processing for a number of sites. For many, the sites become unusable as event-handlers are either not in place or refer to functions that did not have a chance to solidify. Some don't render correctly.
I built a pair of documents illustrating the problem and showed the proxy vendor the difference in behavior when the JS document had a MIME type of "text/javascript" as opposed to "text/html". They told me that their proxy is behaving correctly and that the sites are broken as they are returning incorrect content-type headers.
Their advice was to contact the offending site when I encountered such a problem and ask them to correct the issue.
I should note that this proxy server does have a programming interface. It is possible to alter the behavior of the proxy via this interface to more intelligently inspect documents with "text/html" to determine if they contain HTML markup. My concern was that while I could fix it for my use of the proxy, other users out in the wild would be subject to the same problem.
I'm not a fan of this trend of script-injection, even under the guise of making computing safe for the end-user. I've begun to wonder if it's time to include self-checks in JavaScript code to ensure that no alteration has occurred in transit.
Comments
I have encountered a similar problem with JS injection. There are HTTP proxy servers that inject JavaScript into HTML and JS documents ... I believe the purpose of the injected snippets is to examine the DOM and/or the JS code to try and squelch malicious behavior.
The problem is that this particular proxy observes the MIME type in the content-type header very strictly when deciding to inject raw JS or JS bounded by HTML "script" and "/script" tags.
I've found that a number of sites return a content-type of "text/html" for pure JS documents ... documents often referred to in HTML documents via "script src=xxx". The appliance then injects the HTML "script" tags into the raw JS document, breaking the legal JS code.
This causes the JS runtime to halt processing for a number of sites. For many, the sites become unusable as event-handlers are either not in place or refer to functions that did not have a chance to solidify. Some don't render correctly.
I built a pair of documents illustrating the problem and showed the proxy vendor the difference in behavior when the JS document had a MIME type of "text/javascript" as opposed to "text/html". They told me that their proxy is behaving correctly and that the sites are broken as they are returning incorrect content-type headers.
Their advice was to contact the offending site when I encountered such a problem and ask them to correct the issue.
I should note that this proxy server does have a programming interface. It is possible to alter the behavior of the proxy via this interface to more intelligently inspect documents with "text/html" to determine if they contain HTML markup. My concern was that while I could fix it for my use of the proxy, other users out in the wild would be subject to the same problem.
I'm not a fan of this trend of script-injection, even under the guise of making computing safe for the end-user. I've begun to wonder if it's time to include self-checks in JavaScript code to ensure that no alteration has occurred in transit.