* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ticket #138 (closed design: fixed)

Opened 6 years ago

Last modified 5 years ago

The role of Warning and Semantic Transparency in Caching

Reported by: mnot@pobox.com Owned by:
Priority: Milestone: unassigned
Component: p6-cache Severity: Active WG Document
Keywords: Cc:
Origin: http://www.w3.org/mid/B6A313C5-BD76-45CD-858C-F493B6ADF1F6@mnot.net

Description

Part 6 (Caching) makes warning one of the pivotal features that provide semantic transparency in HTTP caching;

Requirements for performance, availability, and disconnected operation require us to be able to relax the goal of semantic transparency. The HTTP/1.1 protocol allows origin servers, caches, and clients to explicitly reduce transparency when necessary. However, because non-transparent operation may confuse non-expert users, and might be incompatible with certain server applications (such as those for ordering merchandise), the protocol requires that transparency be relaxed

  • only by an explicit protocol-level request when relaxed by client or origin server
  • only with an explicit warning to the end user when relaxed by cache or client

In particular, any of several conditions (e.g., transforming content, using stale responses, failure to revalidate) invokes a requirement upon caches to generate a Warning header. User-Agents are then required to make these Warnings apparent to the end user. Additionally, there are some places where direct notifications to the end user are required, as well as relaxation of MUST-level requirements, upon the condition that the end user is warned (leading to situations where 2616 allows a strongly-stated MUST NOT to be violated; e.g., must-revalidate).

The issue is that very few cache and intermediary implementations (approaching zero) generate Warning headers, and very few user-agent implementations (again, approaching if not at zero) display warnings to users.

As a side note, Warning headers carry very little unique information that's relevant to end users; if the response is stale, this can be determined from examining expiry and Age headers; likewise if a heuristic freshness algorithm is used. While the information that the cache is disconnected or that revalidation failed is potentially interesting to automated agents, it is seldom useful to end users.

Furthermore, "Semantic Transparency" muddles together the roles of intermediaries and caches; while primarily defined in the caching section of the specification, it is more appropriate to discuss it in the context of intermediaries only. Cache-specific transparency is adequately covered by existing requirements.

Change History

comment:1 Changed 6 years ago by mnot@pobox.com

Proposal:

1) Text regarding displaying warnings to end users be removed, and 2) Requirements for generating Warning headers be relaxed, *except* those around transformation, and 3) Requirements that relax other requirements if the end user is informed (such as that for must-revalidate) be removed, and 4) Adding a requirement that caches SHOULD NOT serve stale content except when explicitly allowed, or disconnected, and 5) The concept of 'semantic transparency' be re-specified as applying to intermediaries, not caches.

comment:2 Changed 6 years ago by fielding@gbiv.com

Perhaps we should get rid of the notion of "transparent" altogether. I just noticed that RFC1919 defines "transparent proxies" to be what most people call "interception proxies".

I would prefer transforming and non-transforming intermediaries.

comment:3 Changed 5 years ago by mnot@pobox.com

  • Status changed from new to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.