Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#470 closed editorial (fixed)

What is "Cacheable"?

Reported by: mnot@… Owned by: mnot@…
Priority: normal Milestone: 24
Component: non-specific Severity: In WG Last Call
Keywords: Cc:

Description

p2 4.2.3 defines a method's cacheability as:

Request methods are considered "cacheable" if it is possible and useful to answer a current client request with a stored response from a prior request. GET and HEAD are defined to be cacheable. In general, safe methods that do not depend on a current or authoritative response are cacheable, though the overwhelming majority of caches only support GET and HEAD. HTTP requirements for cache behavior and cacheable responses are defined in[Part6].

However, p6 section 3 prohibits caches from storing a response unless

The request method is understood by the cache and defined as being cacheable

These seem to be incompatible; p2's "method cacheability" is defined in terms of whether a previously stored response can be used to satisfy the current request method, whereas p6 defines it in terms of whether responses to the method can be stored for future use.

The p6 definition (perhaps unsurprisingly) makes the most sense to me, and I think we should align that in p2 with it, adjusting the text in the methods themselves if required.

We also seem to have a number of different types of cacheability defined right now; there's method cacheability, status code cacheability, and overall response cacheability.

While we could invent some new terms (e.g., pressing "storability" into service), I think we could improve things by just using "cacheable method", "cacheable status" and "cacheable response" consistently throughout the specs.

Finally, p2's section on status codes buries this at the end of 6.1 (under a large table):

Responses with status codes that are defined as cacheable by default (e.g., 200, 203, 206, 300, 301, and 410 in this specification) can be reused by a cache with heuristic expiration unless otherwise indicated by the method definition or explicit cache controls [Part6]; all other status codes are not cacheable by default.

This should be moved up (and changed to "cacheable status" as per above).

Change History (6)

comment:1 Changed 6 years ago by mnot@…

  • Type changed from design to editorial

comment:2 Changed 6 years ago by mnot@…

  • Owner set to mnot@…

comment:3 Changed 6 years ago by mnot@…

Addressed by [2373] and [2374].

comment:4 Changed 6 years ago by mnot@…

  • Resolution set to fixed
  • Status changed from new to closed

comment:5 Changed 6 years ago by julian.reschke@…

From [2376]:

Note changes for [2373] and [2374] (see #470)

comment:6 Changed 6 years ago by julian.reschke@…

  • Milestone changed from unassigned to 24
Note: See TracTickets for help on using tickets.