Subject: HTTPS and cache on the client-side

From: Már Örlygsson <[email-masked]>
Date: Mon, 11 Feb 2002 11:05:15 +0000

Hi. I'm doing a research on client-side caching of web documents sent over
HTTPS - if (and how) web browsers respect "Cache-Control: (private)" and
valid "Expires" headers sent by the server over a secure connection.

I've searched the web extensively, but I've come up with very little
reliable information outside the fact that "HTTPS is simply HTTP served over
SSL" and some people second-guessing about browsers not caching HTTPS
documents at all...

Any authoriative information (or insight) would be most appreciated...
...and the development community could also benefit from this knowledge,
as it seems not to be readily available out there.

My problem:

I am part of a team developing a web-app served over HTTPS. The application
is split into several HTML frames (some with comletely static/generic
content) and there are several image files that are an essential part of the
design.

Since bandwidth-use and server-load is a big issue for us, we'd like to
cache as many of the pages/images as possible, while serving the whole
application over HTTPS, as we don't want the users (many of which are one
time users) confronted by dialog-windows notifying them about there being
"both secure *and* insecure items on the page"...

Cheers, and thanks in advance for anything you might be able to share.

-- 
Már Örlygsson
------------------------------
mailto:[email-masked]
http://mar.anomy.net

---

From: "Joris Dobbelsteen" <[email-masked]>
Date: Mon, 11 Feb 2002 15:59:21 +0100

It will depend on what browser you use and how it's configured

IE saves SSL pages in it's private cache. This is possible because every
user has a different cache. But MS provides an option to disable caching of
encrypted content.

I guess browsers will threat encrypted content the same way as unencrypted
content: doesn't matter to them. I suppose you should set up a web site the
same way, whether it's send using HTTP or HTTPS.

Enabling compression is also a good way to save bandwidth. There may be some
complications with bad developed proxies when using HTTP (unsecured).
If you enable Encryption on MS/IIS you should ensure that the content
doesn't expire directly because of compression (see IIS help for more about
this).

Ensure you use encryption as less as possible, as it requires much
processing overhead and content will only be cached by user agents. Ensure
most content is cached by everbody (cache-control: public).
Content that will change regarly must have expire times and preferably
cached by everybody.
Ensure to support reporting "Not Changed" status, which could also save a
lot of bandwidth.
Content that is specific to users and/or contains sensative information
should be cached by the user-agent only, and optionally require revalidation
(getting new content or "Not changed" status).

Indeed, you can sacrafise bandwidth for user-friendlyness: entire page over
secure channel or unsecured channel. I would really recommend this.

Note that home-pages should not be encrypted: this is where most users will
come and hopefully directly leave. Also home-pages don't include sensative
information (usually).
Do authentication over HTTPS, even as sending sensative content. You should
not cache too much about messages about switching between secure and
unsecure channels. This happens at many sites.

You can, like most webmail applications, mix unsecured and secured, in an
effort to save bandwidth and reduce processor utilization.

Hope these suggestions will help you a little bit...

- Joris

>-----Original Message-----
>From: Már Örlygsson [mailto:[email-masked]]
>Sent: Monday, 11 February 2002 12:05
>To: [email-masked]
>Subject: HTTPS and cache on the client-side
>
>

---

From: Már Örlygsson <[email-masked]>
Date: Mon, 11 Feb 2002 17:01:36 +0000

> IE saves SSL pages in it's private cache. This is possible because every

Apparently this is also what Opera does:
<http://www.searchengineworld.com/opera/cache.htm#item219>

When people say that browsers don't cache HTTPS documents, it's not clear if
they're talking about "permanent/extended" page cache, or temporary cache
for the current session only. 

My semi-educated *guess* is that browsers generally cache HTTPS documents
like all other documents, but then clean the HTTPS cache when the browser is
closed.

Does that sound likely?

> effort to save bandwidth and reduce processor utilization.

We're doing this already (mostly). But there remains the issue of linked
static documents such as CSS files, .JPGs and .GIFs and external Javascript
files. We'd like these to be stored in the browser cache for as long as
possible (within the limits of "Expires:" of course) without our users
having to deal with dialog boxes alerting them about "non-secure" items
being loaded and asking them whether they want to load those or not...

> Hope these suggestions will help you a little bit...

Thanks! I'm still searching for more answers.

Any suggestions where to look/ask?