Strange IE behaviour with SSL connections

Hi there!

We stumbled upon a strange SSL/CCS Issue with IE6 and IE7 when we were tuning our homepage Alice. Found was this issue with Pat Meenans Pagetest and HTTPWatch. I am a little bit puzzled and still have not drawn conclusions yet. So here is what happened. For those not familiar with Pats Tool: Dark green is DNS Lookup, Orange is TCP Connection Setup, pink is SSL Handshake, Green is Time-to-first-Byte, and Blue is Data being received.

As the page is done via a Content Management System, we picked one page, which is pretty much representative how all the pages are constructed. The page we picked was this Rechnung, as it is delivered via SSL like almost all of the pages, but does not yet need authentication.

We first had a page with tons of assets. Something like 15 Javascripts in the HEAD, 30 CSS Files in the HEAD, and 20 Images and 20 CSS Images.  The page is normally delivered via SSL, so the initial Connection View of it looked like this:

Clearly you can see it starts to download the CSS and Javascript files on the two sockets IE7 allows per domain. Also you can see between 1.5s and 5.5s the blocking behavior of the Javascript files. Even though having two connections, it doesn’t  use them in parallel.

At roughly 5 seconds it has completed that, starts to render, and downloads all the images. So far so bad.

So we started to optimize and first concatenated all the 30 CSS files to just 5, one being IE7fixes.CSS. This gave us some improvement. You can see that a lot less CSS objects get fetched at the beginning. (The first 4 items are actually newly introduced Redirects due to an Single-Sign-On Service. Yikes.)

But you can still see the painful blocking behavior of the Javascript files.

So what we did then was to concatenate the Javascript files and introduce a second (static) domain, were we would put all the static content. Apart of the Basepage and the Javascript file, everything should reside there, Cookie-free.

And the result is this:

And this seriously puzzled me.  What we see here are at

Line 1 the Redirects and the download of the Basepage.

Line 2 download of the concatenated Javascript file, which is still on the first domain.

Line 3-7 A wonderful waterfall of two connections, with a full TCP and SSL Handshake for EACH CSS FILE…

Line 6-7 The last two SSL Connections are then reused for fetching all the images.

So what is so special about these CSS Files??? HTTP Headers are the same for all of them. Both, Request and Response Headers are HTTP/1.1 with the Header Connection: Keep-alive. And as you can see, for the images it works fine. Why not for the CSS assets?

I did a Wireshark trace and saw, that it is actually me (the Browser) who closes the connection. After receiving the data, I am sending a TCP FIN,ACK. Why does it do so?

So I tested a little bit more and found out, that this behavior is visible with IE6 on XP and IE7 on XP and Vista.

Tests with IE8 on XP showed a totally different picture. Here I got:

Now this is fine. You can see in

Line 1 and 2 that two sockets are used for the Redirects, the basepage, the Javascript and the favicon.

Line 3-4 Opening up 2 new connections to the second, static, domain to fetch the CSS files

Line 5-8 Opening up 4 more connections reaching the maximum limit of 6 connections per domain to fetch all the other assets.

THIS is how I expected the whole thing from the beginning. So I wonder what is going on with IE 6 and IE 7…?

As a final note I tried to fetch the page with IE7 via plain HTTP, no SSL. This is to some degree possible, but leaves me even more puzzled. Here it is:

Line 1 fetches the Basepage and the Javascript file via plain HTTP

Line 2 are the SSO Redirects via HTTPs

Line 3-4 are the CSS files, where it reuses the connection via Plain HTTP, and later on some images

Line 5-6 is fetching two CSS Images via SSL. These connections are NOT reused.

Line 7 fetches some more images

Line 8-13, 15 again a perfect two-connections per domain waterfall, where again CSS Images are pulled via SSL, NOT reusing these connections.

Line 14, 16 some more Images a fetched via plain HTTP, reusing the connection

So we have here with Plain HTTP a reuse of the connections for the CSS Files, the CSS Images though, fetched via SSL, show again the pattern of NOT reusing the connection.

Currently my assumption is, that IE6 and IE7 show this broken behavior, if the following is true:

MULTIPLE CSS Files, served from a DIFFERENT Domain, when fetched via SSL.

A final test would be, to put the CSS files (maybe even the CSS Images?) back on the first domain, and see what happens.

I searched a lot, but was unable to find any known bug for this. If this is indeed a bug and I am not totally misleaded with this analysis.

Any comments/help would be highly appreciated, if this is a known bug, a mistake by myself, or a workaround exists.

Markus

P.S.: In case you wonder: Some of the traces were taken from the UK, some from the US. So do not wonder about the different times to fully download etc.

3 Comments »

  1. Markus Leptien said

    After searching a little bit at webpagetest.org test history, I found here another example for this, were SSL meets a different domain for CSS Images and IE7 shows this “1 Object per Connection” behaviour, even though its HTTP/1.1 with Connection: Keep-alive Header:
    http://www.webpagetest.org/waterfall.png?type=connection&test=091209_3GG7&run=1&cached=

  2. Given this changed in IE8, it’s probably a “bug” – undesired behavior of some edge case. I don’t typically see “timeout” and “max” in the server’s keep-alive response. Remove those and see if it still happens. My only other idea is to test without the Vary response header – I know that affects IE<8 in weird ways wrt caching.

  3. Markus Leptien said

    In this blog entry it is visible, that Gateway seems to have the same issue:
    http://zoompf.com/blog/2010/03/zoompf-check-300-or-gateways-got-a-problem/

RSS feed for comments on this post · TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: