Share on Facebook
Share on Google+
Share on Twitter
Share on LinkedIn
Graceful degredation of redirect using meta http-equiv and Javascript in XHTML, for caching
So, I saw that SSL was becoming more or less mandatory these days, so I got SSL setup for the domain blogologue.com.
However, since I also wanted to keep serving the site over HTTP as well as HTTPS (for graceful degradation and a fallback), and I have a cache sitting between the SSL-server and the weblog system, which pretty much caches everything, all the time, for a long time, I had to do a bit of extra work.
The cache in this setup isn't able to tell the difference between requests coming via HTTP or HTTPS, so an extra '&protocol=http[s]' is added at the end of URLs.
So with this code
<meta http-equiv="refresh" id="meta_refresh" content="1;
http://blogologue.com/?protocol=http" />
<script type="text/javascript">
refresh = document.getElementById('meta_refresh');
refresh.parentNode.removeChild(refresh);
</script>
it is possible to have the page redirect with the protocol key without Javascript, while this piece of Javascript
<script type="text/javascript">
// <![CDATA[
function myOnLoad() {
if (window.parent.document.location.toString().indexOf('http://blogologue.com/frames') != 0) {
if (window.parent.document.location.toString().indexOf('https:') != 0) {
window.parent.document.location='http://blogologue.com/frames?url=http://blogologue.com/&protocol=http';
}
}
if (window.parent.document.location.toString().indexOf('https://blogologue.com/frames') != 0) {
if (window.parent.document.location.toString().indexOf('http:') != 0) {
window.parent.document.location='https://blogologue.com/frames?url=https://blogologue.com/&protocol=https';
}
}
}
document.getElementById('iFrameLoadTest').myOnLoad = myOnLoad;
document.getElementById('iFrameLoadTest').myOnLoad();
// ]]>
</script>
does redirect to setup frames *and* add the protocol key. I setup this site so that it would be possible to access the site without a browser that supports [i]frames, and I guess it is reasonable to expect that a browser that doesn't support Javascript, also doesn't support frames.
Although for example the NoScript extension for Firefox does enable blocking Javascript per-site etc. for security.
So the cache is able to cache http and https pages differently, which again is tidy and neat, as URLs generated on the blog are often absolute starting with http: or https: - and not relative, for example /morphex.
If you're wondering how the meta tag is generated, that's by a script on the server side, which decides to redirect with an &protocol= suffix on URLs, based on an environment variable HTTP_X_FORWARDED_PROTO, which the cache sitting in the middle, is unable to take into account.
It did add "Vary: HTTP_X_FORWARDED_PROTO" to the pages generated in the weblog, but that did not affect the cache.
Now, I was wondering how long a timeout the http-equiv refresh should have, and found 0 was too short, and 2 was too long. If the timeout is 0, it is reasonable to expect that the browser will execute the refresh immediately. It is also reasonable to expect that within 1 second, the following <script> tag is read and executed, and when that Javascript is run, it deletes the meta tag, and from what I can tell, deleting the meta tag, also stops any actions contained within that tag.
You might think that adding <meta> tag within a <noscript> tag in the header would be much easier, and it would be, however, that is not valid XHTML according to the W3C validator, so this "hack" is what will work and be accepted as valid XHTML.
[Permalink] [By morphex] [Web (Atom feed)] [23 Jun 15:18 Europe/Oslo]