To be honest I’m sick of hearing “I hate IE6″, “Death to Adobe”, “All hail HTML5″, and whilst I agree in-part with the enthusiasm of those in the industry embracing standards and forging ahead there is of course a reason we are in the mess we are in, and that reason isn’t going away.

As mentioned at Techchunks, IE6 did come out prior to 9/11, but that doesn’t make it any less relevant now than it was back then.

The sad and ultimately excusable (you would love it to be unexcusable but you don’t have that much money) fact for why IE6 is around is money. Thousands upon thousands of loyal Microsoft-engrained organisations poured umpteen millions of dollars into building proprietary intranet and software platforms on top of ActiveX.

Unfortunately, or perhaps fortunately, ActiveX was removed from IE7 forward and this has left all of those corporates in a position where they must move their internal software systems to something else. Yes, Muicrosoft has been providing migration paths and support for moving away from ActiveX/IE6 for a long time, but it still represents a large expense in IT budgets that managers have been successfully avoiding for a long time.

While ever IE6 happens to be in the top 5 used browsers on your site, are you willing to write off potential sales from those users?

Before you even bother starting with “but they have firefox on their desktops too!” – sorry you are wrong. What they have on their desktops is of no consequence, I have 5 or 6 browsers installed, but you will only see 1 of them in your stats if I visit your site.

Is IE6 a pain in the ass? Yes.
Is IE6 costly to develop for? Yes.
Is IE6 really necessary for my webapp? That’s your choice.

Is IE6 going away in 2010? No. Not a chance. Short of someone writing a virus to remove it from the face of the earth that little browser is here for the long haul.

Unfortunately IE6 is here until managers are willing to cough up the money to move their own apps away from ActiveX. And for anyone who builds websites to make money from visitors, will continue to support IE6 until such a time as it dies out sometime before 2020.

I have been working on a project recently that includes header and footer bars much similar to Facebook style sites, but due to client requirements the site must remain accessible, which rules out using javascript for including the components.

On larger projects ESI has been great for doing remote includes, but due to no ESI support in Apache and no use of proxy/cdn servers in this project ESI was just not going to be possible. SSI of course was the next logical step, something Apache supports, but unfortunately doesn’t allow remote includes.

I thought about including a local proxy file such as a CGI or PHP file which could then issue the remote request and feed the data back, but this seemed hackish. There had to be a better way. It turns out there is.

If you have mod_proxy compiled into Apache then you are all set. Using ProxyPass we can make remote directories pretend to be local directories in Apache, and we can SSI include remote resources over a ProxyPass.

For example, should I wish to include resources from http://foo.com/includes/ I start by creating a proxy pass to my remote resources in my Apache virtualhost.

ProxyPass /remote http://foo.com/includes

I can then use local SSI includes:

 <-- #include virtual="/remote/myfile.html" -->

This is interpreted by Apache and then run through the ProxyPass resulting in an include of the remote file http://foo.com/includes/myfile.html into your local site.

This has certainly made SSI a more usable option for cross-site resource sharing. Best of all – you can do those normal SSI includes inside eZ Publish templates and it gives you even greater flexibility in your projects.