Cache transparency vs. Performance (original) (raw)

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.