Skip to content
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

Method registry should include cacheability #54

Closed
jyasskin opened this issue Apr 9, 2018 · 9 comments

Comments

@jyasskin
Copy link

commented Apr 9, 2018

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.

@reschke reschke added the erratum label Jun 20, 2018

@mnot mnot added the semantics label Oct 10, 2018

@mnot

This comment has been minimized.

Copy link
Member

commented Oct 10, 2018

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

@royfielding

This comment has been minimized.

Copy link
Member

commented Oct 10, 2018

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

This comment has been minimized.

Copy link
Member

commented Oct 10, 2018

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

@mnot

This comment has been minimized.

Copy link
Member

commented Nov 13, 2018

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

This comment has been minimized.

Copy link
Author

commented Nov 20, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Nov 21, 2018

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

This comment has been minimized.

Copy link
Member

commented Feb 5, 2019

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.

@mnot mnot added the discuss label Feb 26, 2019

@mcmanus

This comment has been minimized.

Copy link

commented Mar 25, 2019

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

@mnot mnot removed the discuss label Apr 12, 2019

@mnot mnot self-assigned this Apr 12, 2019

@mnot

This comment has been minimized.

Copy link
Member

commented Jul 5, 2019

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.

mnot added a commit that referenced this issue Jul 5, 2019

@mnot mnot added the has-proposal label Jul 5, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.