-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
caching (POST) requests with bodies #17
Comments
There is no caching a POST, except for the GETtable result of a POST. |
-- https://greenbytes.de/tech/webdav/rfc7231.html#POST So yes, there could be caching if the server opts in. |
No.
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:
|
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). |
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. |
I agree that there are multiple mostly independant issues here:
|
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. |
We still have confusion in the definition of POST, citing the paragraph about cacheability once again:
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. |
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. |
Works for me. |
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)
The text was updated successfully, but these errors were encountered: