Cache transparency vs. Performance
Since there have been numerous discussions of whether semantic
transparency or performance is the more important issue for HTTP
caching, we tried to come to a consensus on what we believed about
this.
-
Applications in which HTTP is used span a wide space
of interaction styles. For some of those applications,
the origin server needs to impose strict controls on
when and where values are cached, or else the application
simply fails to work properly. We referred to these
as the "corner cases". In (perhaps) most other cases,
on the other hand, caching does not interfere with the
application semantics. We call this the "common case".
-
Caching in HTTP should provide the best possible
performance in the common case, but the HTTP protocol
MUST entirely support the semantics of the corner cases,
and in particular an origin server MUST be able to
defeat caching in such a way that any attempt to
override this decision cannot be made without an
explicit understanding that in doing so the proxy or
client is going to suffer from incorrect behavior. In
other words, if the origin server says "do not cache"
and you decide to cache anyway, you have to do the
equivalent of signing a waiver form.
- We explicitly reject an approach in which the
protocol is designed to maximize performance for the
common case by making the corner cases fail to work
correctly.
- We also discussed (in this context) the distinction
between history buffers and caches, which has been
discussed before on the mailing list. Jeffs draft of
January 22 contains definitions for history buffers, but
does not completely describe what the intended behavior
should be. We agreed that although history buffers were
not a part of the HTTP protocol in a narrow sense, that
it was important that service authors and browser
implementors have a shared understanding of what history
buffers (e.g., the "Back" button) do, and that this
should appear in the HTTP protocol spec. Something
along the lines of "if your brower's history buffer
fails to follow this understanding, then these kinds of
services will break: ..."
- ACTION ITEM: Shel Kaphan will write some paragraphs for
the spec that define this shared understanding.
- Shel adds:
At the meeting we discussed whether we believed it would be
reasonable or advisable to think about adding protocol elements to
explicitly control history mechanisms, such as (for instance) a
directive to prevent the entry of a document into a history
buffer. Surprisingly (as I had thought the consensus was
otherwise) people seemed to agree that it was reasonable to
consider some options in this area. We didn't discuss it further.