caching (POST) requests with bodies

[reschke]

When a cache decides to cache a POST (not as GETtable result of a POST), does it need to include the request body into the cache key?

See discussion thread starting at https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/0236.html.

(The answer would apply to other safe methods like PROPFIND as well)

[mnot]

There is no caching a POST, except for the GETtable result of a POST.

[reschke]

Responses to POST requests are only cacheable when they include explicit freshness information (see Section 4.2.1 of [RFC7234]). However, POST caching is not widely implemented.

-- https://greenbytes.de/tech/webdav/rfc7231.html#POST

So yes, there could be caching if the server opts in.

[mnot]

No.

For cases where an origin server wishes the client to be able to cache the result of a POST in a way that can be reused by a later GET, the origin server MAY send a 200 (OK) response containing the result and a Content-Location header field that has the same value as the POST's effective request URI (Section 3.1.4.2).

That defines POST caching; you could define an cache extension to do what you want, but the default semantics of POST are only defined to cache in the manner described above.

Note especially:

A cache MUST write through requests with methods that are unsafe (Section 4.2.1 of [RFC7231]) to the origin server; i.e., a cache is not allowed to generate a reply to such a request before having forwarded the request and having received a corresponding response.

[reschke]

Well, in that case the description of POST is misleading, as it clearly special-cases the "GET-after-POST" variant; thus Part 1 and Part 5 disagree (open a separate ticket for that?)

Other than that, this leaves the question open for safe methods other than GET that include a request body (like it or not).

[rousskov]

At the risk of being accused of playing a lawyer again, "cache the result of a POST in a way that can be reused by a later GET" does not define the only possible POST response caching mechanism. It just defines POST response caching in a way that can be reused by a later GET. It does not define POST response caching in a way that can be reused by a later PROPFIND2 (for example).

Moreover, I do not understand why this issue is scoped to be focusing on (or driven by) POST response caching. POST [special casing] only muddies the waters. The original question, the discussion, and the alleged spec problem had little to do with POST IIRC.

[reschke]

I agree that there are multiple mostly independant issues here:

• an inconsistency between P2 (POST) and P5
• P5 doesn't state whether the request body of a safe method that is somehow cacheable implicitly becomes part of the cache key (and related to that, whether the answer to that is different for GET)

[mnot]

The cache key, as it were, is defined in Constructing Responses from Caches.

There, the second bullet is "the request method associated with the stored response allows it to be used for the presented request". That's the stored request method, however.

So, the stored request method has to allow it to be used for the presented request; POST does that by outlining how it's used for subsequent GETs.

Likewise, if you look at GET, you can see similar language: "a cache may use it to satisfy subsequent HEAD requests unless otherwise indicated..."

So indeed it does not define response caching in a way that can be used by a later PROPFIND2; to do so, you'd need to update the definition of POST.

Back to the original questions -- the reason why POST doesn't define whether the POST body is part of the cache key is that it doesn't use the cache on a subsequent POST, so it doesn't matter; there's nothing to compare it to.

If a future method wants to define how its stored responses can be reused, it can do so (and it can include the request body in that calculation); however, if it wants to change the behaviour of an existing method when presented in a request and there's a stored response with the new method, it needs to update that existing method's definition.

[reschke]

We still have confusion in the definition of POST, citing the paragraph about cacheability once again:

Responses to POST requests are only cacheable when they include explicit freshness information (see Section 4.2.1 of [RFC7234]). However, POST caching is not widely implemented. For cases where an origin server wishes the client to be able to cache the result of a POST in a way that can be reused by a later GET, the origin server MAY send a 200 (OK) response containing the result and a Content-Location header field that has the same value as the POST's effective request URI (Section 3.1.4.2).

To me this clearly says that POST requests are cacheable under certain conditions; it just warns that it isn't implemented widely.

If these are cacheable (not the GET-after-POST variant), we should say how. Or we need to rephrase this section.

[mnot]

Request cacheability does not imply that they can be reused for the same method; it means that they can be stored in the cache, as per the spec.

If you can suggest a way to clarify it so others don't make the same mistake, that would be welcome.

[reschke]

Works for me.