Method registry should include cacheability

[jyasskin]

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.

[mnot]

I think the only concern I have here is that people often misinterpret "cacheable" - e.g., see #17.

[royfielding]

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.

[mnot]

It's not in the registration table, and I tend to agree it should be kept out for the reasons above.

[mnot]

This was discussed regarding Variants, and I think the answer will be the same; we should record this sort of thing in documentation elsewhere, e.g., the wiki.

[jyasskin]

https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#cacheable.methods says

Request methods can be defined as "cacheable" ...

but then the method definitions themselves seem to consistently say

The response to a XXX request is cacheable [if ...]

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

The new method's definition ought to describe whether, how, and under what conditions, a cache can store a response and use it to satisfy a subsequent request.

would have prevented me from getting confused enough to file this issue. Do the experts here like that direction?

[MikeBishop]

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.

[mnot]

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.

[mcmanus]

ietf104: mark needs to research the 7540 question to determine if this can be made editorial based on jyasskin's above comment

[mnot]

7540 points directly to 723x for this, so we have some leeway. I think we can address this by parenthetically stating that a method that does not define the conditions under which it can be used by a cache is by definition not cacheable.

Will do a PR.