Morphex's blogologue (Life, technology, music, politics, business, mental health and more)

This is the blog of Morten W. Petersen, aka. morphex in various places. I blog about my life, and what I find interesting and/or important. This is a personal blog without any editor or a lot of oversight so treat it as such. :)

My email is morphex@gmail.com.

An OGG/Vorbis player, implemented in Javascript.

My Kiva bragging page
My shared (open source) code on GitHub

Morphex's Blogodex

News
Slashdot

Zope hosting by Nidelven IT

Morten Petersen on Linkedin

Morten Petersen on Facebook

Morten Petersen on SoundCloud

Morten Petersen on MixCloud

Blogologue on Twitter



Older entries



Atom - Subscribe - Categories

Facebook icon Share on Facebook Google+ icon Share on Google+ Twitter icon Share on Twitter LinkedIn icon 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]