header, part deux

Surely, my non-existent audience can’t wait for another installment of the header saga. To recap: we have a piece of code, a header, that needs to go on every intranet page, but the sheer number of distributed servers makes that sliiiightly difficult.

So, here I was, looking into any possible workaround for this insane problem that the designers of every server and every programming platform have created for us in the name of security. Then, as I was looking at JSON or something similar, it hit me: what if we coded up the header INSIDE as a JavaScript snippet?

At first, I laughed at myself, and called myself an idiot. Then, I started thinking… a piece of JavaScript code can be downloaded from any server – if you’d like, you can run JavaScript from Microsoft in your browser – it’s all client-side. Sooo… I started coding, and this is what this craziness now looks like:

- the page that lives on some random server includes an iframe that starts off at 0px height
- the iframe calls another HTML file that has an onload JavaScript to resize the parent iframe to fit its size (everything is kosher here, we’re on the same server)
- here’s the kicker – the iframe source file makes a call to a JavaScript function that resides on the main intranet server that we have full control of
- this JavaScript function document.writes out the header code, CSS and all
- once the iframe source loads, the aforementioned script resizes the iframe so that the header is there to be seen

The net effect is that if JavaScript is disabled, or if the main server takes too long to respond or is down, the header would not display. Because of the iframe, the page that started this whole thing can load up unaffected by what’s going on the main server.

What’s crazy is that the header code is not even written out to disk – it exists only in the client’s browser memory. And yet the darn thing works.