Method registry should include cacheability #54
HTTP Methods have 3 boolean properties, all of which 8.1.2 says a registration needs to define, but only "Safe" and "Idempotent" were included in the registry while "Cacheable" was omitted.
I filed this as https://www.rfc-editor.org/errata/eid5300, but it probably makes more sense as a change for ter.
The text was updated successfully, but these errors were encountered:
FWIW, that's because it isn't a boolean property of the method, but rather a capability inherent in the system in which one aspect is the method semantics.
I'd prefer to remove that from the registration table. We could still require that the registration describe how and under what conditions the method semantics might be cacheable.
but then the method definitions themselves seem to consistently say
After this discussion, I think the method definitions ("The response is cacheable") are more correct, and that therefore my initial suggestion in this erratum is incorrect.
https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#considerations.for.new.methods repeats the less-correct form by listing "cacheable" along with "safe" and "idempotent" as properties of the method. I think removing "cacheable" from that list, and changing "If the new method is cacheable, ..." to something like
would have prevented me from getting confused enough to file this issue. Do the experts here like that direction?
Note that RFC7540 Section 8.2 relies on that distinction by saying that pushed requests MUST be cacheable in order to be pushed, but conditionally defines what happens if the delivered response does turn out to be cacheable. Eliminating the distinction entirely would leave 7540 slightly unmoored.
I think the proposed edit to considerations for new methods is helpful; we could address the 7540 concern by parenthetically adding "also known as cacheable methods" or similar.
Note also the first bullet of storing responses. If we can come up with a better phrase than "defined as cacheable" that's great, but it needs to be distinct from response cacheability.