There is quite odd behavior with MOSS cache: Imagine you create a site with two areas, one that can be accessed by http and one which must be accessed using https.

So you need to enable https in your site, etc… Alright, so how do you make the users access the secure zone by using https, you do two things:

• You link to the secure zone by using https.
• You write some code in the master that gets the path of the current page and if the page is in the secure zone and the HttpContext.Current.Request.Url.Scheme is http, redirects to the equivalent https page.

So far, so good… The problem? Once you enable the cache you can see the pages bypassing the https if the page is cached:

1. Someone enters the page using https, so the page is stored in the cache.
2. You try accesing the page using http, the moss looks in the page for a cached “copy” and finds the cached page, so it does not check the protocol, so the cached page matches and it is “responsed” to the client, since the page is cached, the code of the master is not executed.

The bad-ugly solution:

Add a jscript in the pages of the secure section that redirects to https in case the page is accessed by http. The problem is that javascript can be easily bypassed or maybe the visitor has disabled it. A very inelegant solution indeed.

The cool (for us at least) solution.

Since we already used a module that implemented the “VaryByCustom” method, we added the schema (http or https) to the string that MOSS uses to decide the “key” of the page in the cache copies.

So when the user accesses the page using https, the cached copy corresponds only to the https version. When the user accesses the page using http, the cached copy is not used and the code is executed, sending the user to the same page but using https.

The way to extend MOSS (and any asp.net web application) cache capabilities is explained in the “How to: Extend Caching by Using the VaryByCustom Event Handler”.

Hope it helps!