W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 2002

RE: HTTPS and cache on the client-side

From: Joris Dobbelsteen <joris.dobbelsteen@mail.com>
Date: Mon, 11 Feb 2002 15:59:21 +0100
To: "'Már Örlygsson'" <mar@anomy.net>
Cc: "WWW WG \(E-mail\)" <http-wg@cuckoo.hpl.hp.com>
Message-ID: <000401c1b30c$b0896ba0$0d0ba8c0@joris2k.local>
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:mar@anomy.net]
>Sent: Monday, 11 February 2002 12:05
>To: http-wg@cuckoo.hpl.hp.com
>Subject: HTTPS and cache on the client-side
>
>
>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:mar@anomy.net
>http://mar.anomy.net
>
>
Received on Monday, 11 February 2002 14:59:49 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:45 EDT