If you use only HTTP, the Apache virtual host feature will do the magic already for many years. But with HTTPS you are out of luck until now. The problem is the TLS handshake, which does not have something like the Host header in HTTP. Because the HTTP stream is covered by encryption until the TLS handshake is done, Apache has no chance to read the Host field to choose the right virtual host from the beginning on. So you are out of luck to deliver the right certificate to the client. Certificate hostname mismatches will arise in the users browser, which is not desirable.

As a solution for this secure virtual hosting problem the RFC 4366 defines SNI in section 3.1. The first RFC where SNI is mentioned is RFC 3546 which was issued in mid 2003, but until today in early 2008 Apache does not support SNI per default. It seems to be a chicken and egg problem as described in SNI doesn’t work in practice. On the one side the major web server Apache does not support it and on the other side the major browsers were slow to jump on. Opera 8 was the first in 2005, but important public browsers like IE are still lacking support. Also major sites don’t bother because they have enough IP’s.

Browser Compatibility Table

I compiled a browser compatibility table to document the status of TLS/SNI in April 2008. If you look at the table, the problem is located at WinXP and Webkit. While I assume that Webkit browsers will match up on OSX and Linux, I’m not sure about WinXP. On WinXP the lack of support (at least for IE) is in the OS itself. IE7 running under Vista has support for SNI, but under WinXP not.

[1]

Tested as not working with IE 6.0.2900.2180 on WinXP SP2 without any updates.

[2]

According IEBlog: Upcoming HTTPS Improvements in Internet Explorer 7 Beta 2. Tested as not working with IE 7.0.5730.13 on WinXP SP2 with all updates until 04/22/2008.

[3]

Tested as not working with IE 8.0.6001.17184 beta on WinXP SP2 with all updates until 04/22/2008.

[4]

According to bug #116169. Tested as working with Firefox 2.0.0.12 on Ubuntu 7.10 with all updates.

[5]

Tested as not working with Safari 3.1.1 (525.18) on WinXP SP2 with all updates until 04/22/2008.

[6]

Tested as not working with Konqueror 3.5.5-ubuntu3 on Ubuntu 6.10 with no updates (plain DVD). I only installed Konqueror from edgy main.

[7]

More info at bug #122433.

At the End

I think its not feasible to use SNI today. Its best to look at it again in one or two years. I found another solution for my HTTPS problem. I use one certificate for the whole server, which has multiple domain names in it. Its possible through multiple SubjectAltNames in the certificate. CAcert issues such certificates. All browsers accept certificates where the domain name matches one of the DNS SubjectAltNames.

Resources

• a SNI test site, so you can see if your environment supports it.
• Daniel Lange’s summary of what supports SNI
• the apache ticket to add SNI
• the lighttpd ticket to add SNI
• VhostTaskForce at CAcert wiki
• VhostsApache at CAcert wiki
• Paul explains how TLS Server Name Indication works.
• Ubuntu Apache TLS to support SNI Blueprint

While the fastest way for manual link checking is the LinkChecker Firefox Plugin, it is not so easy to check our whole site for 404’s. Same thing with validation. For fast manual checking of a single page I would recommend to install the Web Developer Toolbar in Firefox and simply press Shift + Ctrl + H or Shift + Ctrl + A. But how to validate all pages or our site? And how doing it offline for performance reasons?

My approach is to mirror the whole web site with wget, look at the wget log for dead links and use the WDG Offline Validator to validate the mirrored HTML pages.

Mirror with wget

I assume, you use Linux or a Unix like system. So wget wouldn’t be new for you or you will be able to get it for your system. It’s a pretty basic but powerful tool.

First you should create a new directory where wget could download all your pages. On your console you can execute this command line to get your whole site:

1. wget --mirror --keep-session-cookies -o wget.log

I use the --mirror switch to simply fetch all. The --keep-session-cookies switch is useful is your site is dynamically created as this blog for example. -o wget.log says, it should put the output into this file. Be sure your server would hold against the stress!

Once wget finishes, you could use less or your favorite editor to search inside the wget.log for 404’s and the string error. This is all what you will need for link checking.

Validation with the WDG Offline Validator

I searched a while for a usable offline validator. The W3C one is a CGI script which needs a running Apache and you have to do a HTTP post in order to check your local HTML file. It is basically the same thing as the public W3C Validator. The next one I did not choose is a Windows application called A Real Validator. The disadvantages are that it costs money and has a little bit dated GUI which does not allow to filter for only invalid pages. So you have to scroll though hundreds of valid pages to find your invalide ones.

So at the end I use the WDG Offline Validator. You can get it from this site but the best thing is that Debian and Ubuntu have it available in there package repositories. So you can just type:

1. sudo apt-get install wdg-html-validator

(Be sure you have the universe repository in our list.)

To validate all the HTML pages wget downloaded, just type:

1. find . -name "*.html" -exec validate -w {} \; > validation.log

This command finds all yout HTML files in your current directory, executes the validate command on everyone and outputs the results in the validation.log file. While this runs, you can look at the validation.log with tail or you can view it afterwards in whatever editor you like best.

So that is basically all what you need to check your whole site for dead links and valid HTML.

On 456 Berea Street I read the following on the Accessibility Page:

This site is built on valid HTML 4.01 Strict for structure and CSS for presentation.

A modern web browser like Firefox, Safari or Opera is needed to make the most out of this site, but thanks to the separation of content and presentation it should be accessible to any browsing device, including Internet Explorer.

Take this as the funny part of this post. Now I’m going into the silly HTML vs. XHTML discussion.

HTML 4.01 Strict?

So the real cracks use HTML 4.01 Strict today even if they used XHTML in the past. The key point choosing XHTML is senseless today is that you have to deliver (X)HTML pages as text/html because the famous Internet Explorer doesn’t understand application/xhtml+xml. But if you deliver as text/html all browsers interpret your nice XHTML as tag soup anyway. Thats why some of the people caring about this stuff switched back to HTML.

After playing some time with Wordpress and its Themes/Plugins I realized that it is not simple to switch to HTML 4.01 Strict. The whole Wordpress world uses XHTML 1.0 and every single peace outputs /> instead of > on empty tags. So without rewriting nearly all Wordpress code, it would not be possible to generate real valid HTML.

The other fact that pushes me towards XHTML is a article of Christoph Schneegans which reads XHTML oder HTML?. He says that a HTML Validator wouldn’t complain about valid SGML shortcuts which can cause rendering errors in browsers. To cite him – this markup is perfectly valid HTML:

1. <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
2. <>
3. <title//
4. <p ltr<span></span</p>
5. </>

and it is equivalent to:

1. <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
2. <html>
3. <head>
4. <title></title>
5. <body>
6. <p dir="ltr"><span></span></p>
7. </body>
8. </html&gt

To summarize: I will use XHTML 1.0 Strict delivered as “text/html” for now and maybe (X)HTML5 later on in some years.