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

Ticket #139 (closed design: fixed)

Opened 6 years ago

Last modified 4 years ago

Methods and Caching

Reported by: mnot@pobox.com Owned by: mnot@pobox.com
Priority: normal Milestone: 11
Component: p2-semantics Severity: Active WG Document
Keywords: Cc:
Origin:

Description

RFC2616 does not clearly define what the relationship of the request method is to caching. In particular, does the method form part of the cache key?

If the method does not form part of the cache key, a cache can effectively only be used to satisfy GET and HEAD requests, but a non-GET/HEAD response could "populate" the cache if it had explicit expiry information; e.g., a POST response could be used to satisfy a future GET request (if the POST response were marked as explicitly cacheable).

If the method does form part of the cache key, any method (e.g., OPTIONS, PROPFIND) could potentially be cached and returned in response to future requests.

Relevant text;

9.5 POST: Responses to this method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields.

13.11 Write-Through Mandatory:

All methods that might be expected to cause modifications to the origin server's resources MUST be written through to the origin server. This currently includes all methods except for GET and HEAD. A cache MUST NOT reply to such a request from a client before having transmitted the request to the inbound server, and having received a corresponding response from the inbound server. This does not prevent a proxy cache from sending a 100 (Continue) response before the inbound server has sent its final reply.

IME current implementations do not cache any non-GET/HEAD responses, so either path is open.

Change History

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

  • Component changed from p6-cache to p2-semantics

p6 changed to make both storing and reuse contingent upon the method allowing it.

Now need to change p2 to specify caching semantics for GET, HEAD and POST, and reaffirm that DELETE and PUT can't be cached.

e.g.,

  • GET can be stored, and reused when the presented request method is GET or HEAD.
  • HEAD can be
    • stored and reused when the request method is HEAD, or
    • used to update existing GET cache entries.
  • POST can be stored, and reused when the presented request method is GET or HEAD.

It's also worth considering putting a slot into the method registry to capture this. Additionally, when we document method extensibility, this needs to be covered.

comment:2 Changed 4 years ago by mnot@pobox.com

  • Owner set to mnot@pobox.com
  • Priority set to normal

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

  • Milestone changed from unassigned to 11

comment:4 Changed 4 years ago by mnot@pobox.com

From [888]:

Define caching requirements for methods (see #139).

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

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

comment:6 Changed 4 years ago by julian.reschke@gmx.de

From [889]:

Note change in [888] relating to issue 139 (see #139)

comment:7 Changed 4 years ago by mnot@pobox.com

From [891]:

Remove TODO for updating p2 methods; done (see #139).

comment:8 Changed 4 years ago by fielding@gbiv.com

  • Status changed from closed to reopened
  • Resolution incorporated deleted

But we discussed this before and WG consensus is clear that the method is part of the cache key. In particular,

Responses to POST requests are cacheable only when they include explicit freshness information (see &p6-explicit;). Such cached POST responses &MAY; be used to satisfy subsequent GET and HEAD requests. Note that POST caching is not widely implemented. However, the 303 (See Other) response can be used to direct the user agent to retrieve a cacheable resource.

Is not quite right. The response to a POST has nothing to do with the response to a GET on the same URI unless the response is 200 and contains a Content-Location with that URI. A POST response that is marked as cacheable without the Content-Location would indicate that the POST itself can be cached. This could only be used when the POST body is empty and the POST action happens to be idempotent, which is so rare that nobody implements it in practice. However, that is better than special-casing responses to POST to be unlike all of the other non-GET methods.

comment:9 Changed 4 years ago by mnot@pobox.com

From [910]:

Require Content-Location on POST responses in order to use them to satisfy a GET/HEAD (see #139).

comment:10 Changed 4 years ago by mnot@pobox.com

  • Status changed from reopened to closed
  • Resolution set to incorporated

comment:11 Changed 4 years ago by mnot@pobox.com

  • Status changed from closed to reopened
  • Resolution incorporated deleted

comment:12 Changed 4 years ago by mnot@pobox.com

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