Question

My session cookie is somewhat long (about 700 bytes), since it contains various encrypted user information and what not. There’s some things I can do to get that size down, and I’m working on that angle too, but that’s another topic.

My issue is that I don’t like how this cookie gets sent to the server on every single HTTP request; including requests to JPG images, CSS files, and static Javascript files. Since the cookie isn’t needed on these requests, I feel it might slow down page load times since this is 700 bytes x the number of resources the page loads. Obviously, these files get cached and what not but still I’d like my pages to load and quickly and smoothly as possible.

The one solution I can think of is to put all my static content on another sub-domain, such as cdn.myserver.com/images/ and cdn.myserver.com/scripts/, and set the cookie-path to only include www.myserver.com. I believe this would work, but it complicates dev and staging environments. I’d probably end up having to generate URLs dynamically depending on what environment the code was being run in.

My Question:

Besides the solution above, is there any way to prevent cookies from being sent across the wire for certain HTTP requests, such as image, script and style resources?

I’m running on the .NET stack, with IIS7.5 as a web server.

Answer 1

There isn’t anything you can do from a server perspective; by the time your server (IIS) or your framework (ASP.NET, or other) has received the request, the cookies have already been sent.

What you mentioned will absolutely work, quoting RFC 2109 ("HTTP State Management Mechanism") (emphasis mine):

Hosts names can be specified either as an IP address or a FQHN string. Sometimes we compare one host name with another. Host A’s name domain-matches host B’s if

• both host names are IP addresses and their host name strings match exactly; or
• both host names are FQDN strings and their host name strings match exactly; or
• A is a FQDN string and has the form NB, where N is a non-empty name string, B has the form .B’, and B’ is a FQDN string. (So, x.y.com domain-matches .y.com but not y.com.)

Note that domain-match is not a commutative operation: a.b.c.com domain-matches .c.com, but not the reverse.

So creating a separate sub-domain, while specifically keying your cookies to a different sub-domain will work.

Note that it’s commonly accepted practice to do this in order to increase page speed and Stack Overflow has been doing this since late 2009.

In order to reduce the complexity of your staging and dev environments, I recommend following this lead; having the content on a separate domain means that you don’t have to do anything different for any of those environments.