Create separate caches for pages accessed through http and https

My problem is, that I would like to cache pages for anonymous users that visit the site through https. Right now I can't, because it makes the site unusable for anonymous users through http. That means, that https uses no cache at all (or just the views cache) which slows things down a lot.

Thanks for your answer.

There are many ways to do this if you really want to, but as mentioned before HTTPS disabling is there for a reason. You could duplicate the block of boost rewrite rules and assign something other than "normal" as the variable, and then hack boost.module to add another folder if HTTPS is set.

That might be an option, but hacking the module isn't really what I want to do. It would be nice to have that functionality to optionally use it.

Or you could redirect all non-SSL requests to a differing domain/ ip address and then disable the HTTPS on rule which would require substantial relinking of your site but would negate needing to modify boost to use a differing directory other than normal.

I don't really like that Idea. I prefer to have just one domain for both http and https

You could also redirect all anonymous users to the non-ssl site using a rewrite rule too. (safest and easiest option)

I think that's rather the unsafest option because then all anonymous traffic would not be encrypted. I would like better to encourage users to use https to protect their privacy.

I'd be very careful with the rewrite rules to make sure that no user information is accidentally cached.

Definitely. But I think there is a misunderstanding: Using https or not doesn't say anything about which part of the website I'm using and what data I am sending. It's the module's task to determine whether or not content should be cached, but that doesn't have anything to do with http or https.

Thanks for your answer Philip_Clarke. But I still disagree on some points or maybe I haven't understood you right.

The problem with caching https is that although boost would not cache a POST request. It would cache a return value from a password form, e.g. Joe enters his password wrong, his username appears on the cached page returned to the browser so then everyone else sees his username even if there is no password value.

I see the problem, but not the connection to https. For example, the login form shouldn't be cached for what you said. But that is true independent from visiting it through http or https, i.e. the criteria to decide if a page is cached or not is it's content but not the way it is delivered to the visitor. That's what I meant when I said that "it's the module's task to determine whether or not content should be cached". Or am I wrong?

For "the boost project" to create to differing caches would require duplicating virtually everything in admin, from the cache lengths through to the pages covering excluded pages, and would mean shipping a module that was insecure by default with the inherent risk of presenting cached information to anon users.

I'm not sure what you mean by "duplicating virtually everything in admin", but wouldn't a separate cache for https technically be the same as the cache for a subdomain?

No it's the site owner's task to configure boost and determine what should be cached or not, removing the one line from the .htaccess file gives the option to cache https.

But the line in .htaccess does not have any effect on how the pages are cached, right? Just to get back to the main problem that made me open the feature request: If you use a self-signed certificate for SSL and parts of the cached page include https calls (for example images) then they won't be visible to users that haven't added an exception rule for the certificate. That is why I proposed to create a separate cache for https so that there can be a cached version of every page once with http and once with https.

although https doesn't protect privacy and in the case of boost it worsens it by instructing the browser to cache pages for long periods of time, the only thing https does is encrypt content from a man in the middle, it doesn't stop an ISP saying at X hour user Y connected to website Z, for that you would need Tor.

Yes, you're right. But at least the content exchanged between client and server is encrypted. How does https instruct the browser to cache pages for long periods of time?

Thanks again for the quick reply, Philip_Clarke. I really do not want to appear ignorant, but I still don't see how https is a cause of the problems you describe. I understand the problem to detect whether or not a page should be cached and that it becomes harder if there are custom elements in the site. And as far as I can tell, the module does a great job in this.

But: Let's take the login block as an example. Somehow Boost needs to 'know' that it shouldn't cache a page if it contains a login block (or is the login page). But although it is more likely, that a page visited through https contains forms to send data to the server, that is not a reliable criterion to determine whether a page should be cached. For example, visiting http://example.com/user should not be cached (although it is http) while https://example.com should be (although it is https). See what I mean?

From what I've seen of the site then you would be looking at editing drupal core for the image links for each article to instruct them to look for http or https access before even getting to boost as the mix and match nature of drupal's link construction is not compatible with self signed certificates or indeed mixing https on a http page.

I think it's possible to have Drupal create https links on https pages and http links on http pages, although in some cases it means a little more thinking for developers. But I think it is ok to leave that to them, because the module's task is to cache the content that is put out and the rest is the site developer's task.

setting up multiple domains would mean copying content across

Right now I am using a subdomain for a mobile version of the site (m.example.com) and it is also cached - in a different directory. By "copying content across" do you mean the fact that there are multiple folders containing caches, like it is done for subdomains?

Any more ideas on this topic? Unfortunately my knowledge is too limited to contribute with programming at this level.