Server-side Includes on Static Resources
-
You have to love people who have apparently learned how to include another file from the server, but not that <script> has a "src" attribute. All over the place, I'm seeing:
<font face="Courier New"><link type="text/css" rel="stylesheet" href="../res/style.css">
<script>
<!-- HIDE JAVASCRIPT
<%@include file="../res/script.js"%>
// END HIDING -->
</script></font>
Because allowing the browser to cache resources is lame, I guess. By using a server-side include, we can increase the server load (by requiring it to open extra files for a request), and by placing this in a dynamically created page (so the page can't be cached) we can almost double the amount of bytes we're sending over the network!
For added fun, the CSS stylesheet is referenced via an external resource, so it's not like the person writing the page couldn't figure out the relative path.
-
Why is it '<font face="Courier New">HIDE JAVASCRIPT'<font face="Times New Roman">? The include is done server side after all, so it's still sent to the client, it's not gonna hide it at all.</font>
</font>
-
@Sunday Ironfoot said:
Why is it '<font face="Courier New">HIDE JAVASCRIPT'<font face="Times New Roman">? The include is done server side after all, so it's still sent to the client, it's not gonna hide it at all.</font>
</font>The Hide Javascript are HTML comments to hide JS from browser's SGML parsers. Because a few years ago some crappy browsers which neither understood JS nor understood the <script> element used to try to interpret javascript as HTML.
-
@Xenoveritas said:
You have to love people who have apparently learned how to include another file from the server, but not that <script> has a "src" attribute. All over the place, I'm seeing:
<FONT face="Courier New"><link type="text/css" rel="stylesheet" href="../res/style.css">
<script>
<!-- HIDE JAVASCRIPT
<%@include file="../res/script.js"%>
// END HIDING -->
</script></FONT>
Because allowing the browser to cache resources is lame, I guess. By using a server-side include, we can increase the server load (by requiring it to open extra files for a request), and by placing this in a dynamically created page (so the page can't be cached) we can almost double the amount of bytes we're sending over the network!
For added fun, the CSS stylesheet is referenced via an external resource, so it's not like the person writing the page couldn't figure out the relative path.Unfortunately I can one-up this one. We are using a web-cms program here which will remain unnamed except that it is produced by Do******um. It requires that we have our IIS servers configured to treat .htm extensions as .asp. Because it needs to use server side includes.
WTF 1: Why is a WebCMS using server side includes? why isn't it just combining the code before publishing?
WTF 2: If you are going to use Server Side includes (SSI), how about treating .htm as .shtml instead? Also supports SSI, but doesn't need anywhere near the memory and CPU hits of ASP.
WTF 3: As you can imagine, we have major problems with caching, because the files are .htm, and when you update an include the actual .htm is not modified, it can take up to 24 hours (or more) for a page update to propogate through to browser cache's, etc. (yes I know we could default the cache expiry, and we have, but even with that, not all proxies honour the cache expiry on .htm)
