2
Vote

current protocol should be used to construct CacheKeys

description

In RequestProcessor, the cache key is constructed as such:
        CacheKey = string.Join("/",
                              new[]
                                   {
                                       CachePrefix,
                                       typeof (RequestProcessor).ToString(),
                                       setName,
                                       version,
                                       Compressor.EncodingName
                                   }.Concat(CacheVaryStates.Select(s => s.Key)).ToArray());
I believe that the current protocol (http vs https) should be considered when constructing this cache key.

I've run into problems with absolute paths and mixed content warnings when I assumed that:

http://blah.com/combres/set and https://blah.com/combres/set would return entirely different resources (they should really, as they could represent entirely different content)

comments

buunguyen wrote Sep 14, 2011 at 3:18 PM

Isn't it the case that the HTTPS and HTTP apps run in separate processes? How can Combres be loaded into one single process serving both HTTP and HTTPS at the same time? Can you elaborate the use case?

dplaskon wrote Sep 14, 2011 at 3:54 PM

Buu,

That is not the case - if you setup a site in IIS to use http/https, the same process serves it, and thus, combres will cache only one copy of the site for http/https.

You can verify this by setting up a site as described and running some sort of filter that manipulates a resource set file (say a css file by setting different paths if the current request is secure or not), you can see that subsequent requests are served up with whatever the first request was due to it being cached.

dplaskon wrote Nov 17, 2011 at 5:30 PM

I believe all that would be required is to construct the cache key as follows in RequestProcessor:
        CacheKey = string.Join("/",
                              new[]
                                   {
                                       CachePrefix,
                                       typeof (RequestProcessor).ToString(),
                                       setName,
                                       version,
                                       Compressor.EncodingName,
                                       Context.Request.IsSecureConnection.ToString()
                                   }.Concat(CacheVaryStates.Select(s => s.Key)).ToArray());
Would you consider making this revision?

buunguyen wrote Jan 5, 2012 at 5:21 AM

Isn't it the case that the content of a resource set the same regardless of the protocol used?

buunguyen wrote Jun 2, 2012 at 7:29 PM

I see what you meant now, didn't read the 2nd paragraph carefully. In that case, you should use the cache-vary provider mechanism Combres supports. This is not a well documented feature, you can check out the sample in SampleCommon project, read documentation of ICacheVaryProvider and CacheVaryState and combres_full_with_annotation.xml. Basically you need to implement something like a ProtocolCacheVaryProvider and associate it with one or more resource sets.

buunguyen wrote Jun 2, 2012 at 7:32 PM

One more note: I'll be happy to receive a patch or documentation support once you've done that :). My hands are tight right now so contribution is greatly appreciated.

dplaskon wrote May 7 at 5:33 PM

Buu,

I think a more idiomatic solution would be to make the proposed change to the way the cache key is constructed in RequestProcessor (see my comment from Nov 17, 2011 at 1:30 PM). Is there some reason you believe this wouldn't be a good solution to the underlying issue here?

buunguyen wrote May 7 at 6:08 PM

Modifying cache key the way you suggested is certainly one way to make this works. The reason I suggested building a custom cache-vary provider is because this approach increases the mem footprint and 1st-time performance hits for users who don't have to need to differentiate between HTTP and HTTPS requests (i.e. they don't use filters which modify content differently based on secure-connection status).

dplaskon wrote May 8 at 12:33 AM

Buu,

I could be mistaken - but I think there is an issue with cache-vary providers in nested groups (at least there was the last time I played around with making one) - are you aware of such an issue?

Sign in to add a comment or to set email notifications