To start this blog, I encourage you to play along with me: clear your browser’s cache and history, disable JavaScript and visit Apple.com/retail/sanfrancisco, the direct link to the San Francisco Apple Store. If you are like me, you should see a magnificent white page, stopping you in your tracks. Now, enable JavaScript again and click on the same link: the San Francisco Apple Store page should now load, with, indeed, a URL redirect. Interesting, isn’t it?
A look at the infamous white page reveals it directly calls some JavaScript code hosted on the Apple Servers that, from the date, computes a special URL you should be redirected to.
Something bad? Well, the code certainly is not malicious by any means so there is nothing truly bad at play. By guessing URLs, one can also crawl back through time and look at archived San Francisco store pages so the redirect does have an upside. It does however seem like a rather complex and contrived way to display a changing page. And it also makes it more difficult for those relying on screen readers and mobile browsers to access the page.
Now, I am sure there is a reason I am not thinking of. But what could it be?
CMS - it makes sense
If I'm Apple and I have a large web site edited by tens or hundreds or even thousands of people (depending on the element), I need a content management system, or a CMS. Using my CMS, I can then schedule content that appears or disappears based on a date and time in a specific time zone, in the user's home time zone, etc. So this makes sense to me.
Why you have to call a JavaScript to get the CMS ball rolling is a little odd to me -- it could be a little more hidden. However, it's possible that the entire site is homegrown using WebObjects and other code, and maybe it was just easier for them this way.
In any case, the scheduling function is critical to a company like Apple that's selling to millions around the globe.
CMS - it makes sense
Now that I think a little more about it, it makes even more sense. By asking the client system to execute the JavaScript code and thereby call on specific web content, the web server can bypass calculating which content to provide -- the client already specified precisely what it wants. Apple has off-loaded the initial processing to the client. They've also let us peer into their system a bit, but most users will never, never notice and the security risk is limited. I suspect they could put future-dated content (new iPods, Macs, software) off-limits at a higher level in the CMS rulebase.
More in the past
Yes, they've always used a lot - and more, I think, in the past. Two or three years back Symantec's filtering software (forget the name but it's part of the Norton Internet Security), which blocked a lot of it, would make the Apple pages pretty much unusable.
Re:
They could use this little-known feature in that obscure protocol, you know, the “redirect” status in the “HTTP” protocol. I hear it’s actually supported quite well for such a brand-new standard. (It dates back no further that 1992! That’s like, yesterday.)
But then, Apple has always been an abysmal citizen of the web. For the latest case, have a look at how they botched their “photocast” spawn:
http://lists.apple.com/archives/syndication-dev/2006/Jan/msg00020.html
Re:
I agree that they should use HTTP redirects, but in my experience larger organizations the server people and the actual page writers don't play nicely together, which is where extraneous hacks like this one comes from.
In an ideal world, people would just use the tools that are established to do what they want, rather than feel forced to reinvent proven methods (usually for the worse).
This is bad in another way
What if the user bookmarks the end page and comes back a couple of weeks later will he still have the old schedule?