HTTP Caching
draft-ietf-httpbis-cache-19
Yes
No Objection
Note: This ballot was opened for revision 16 and is now closed.
Francesca Palombini Yes
Murray Kucherawy (was No Objection) Yes
Alvaro Retana No Objection
Erik Kline No Objection
[S4.3.1] [question] * What does it mean to "validate a response that [the cache] cannot select with the request header fields it is sending"?
John Scudder No Objection
Lars Eggert No Objection
Section 3. , paragraph 2, comment: > A cache MUST NOT store a response to a request unless: Unless all of these are true or any of these are true? I guess the former. ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 2. , paragraph 2, nit: > Proper cache operation preserves the semantics of HTTP transfers > ([Semantics]) while reducing the transmission of information already It's unusual to put a reference (also) in parentheses; suggest removing the parentheses here and checking similar occurrences throughout the document. Section 1. , paragraph 5, nit: - HTTP caching's goal is significantly improving performance by reusing - ------- + The goal of HTTP caching is significantly improving performance by reusing + ++++++++++++ Section 1.3. , paragraph 5, nit: > uses to select a response and is comprised of, at a minimum, the request met > ^^^^^^^^^^^^^^^ Did you mean "comprises" or "consists of" or "is composed of"? Section 9.1. , paragraph 3, nit: > ferring to RFC 723x. * Remove acknowledgements specific to RFC 723x. * Move > ^^^^^^^^^^^^^^^^ Do not mix variants of the same word ("acknowledgement" and "acknowledgment") within a single text. Section 9.1. , paragraph 3, nit: > pecific to RFC 723x. * Move "Acknowledgements" to the very end and make them > ^^^^^^^^^^^^^^^^ Do not mix variants of the same word ("acknowledgement" and "acknowledgment") within a single text. These URLs point to tools.ietf.org, which is being deprecated: * https://tools.ietf.org/html/draft-ietf-httpbis-messaging-16 * https://tools.ietf.org/html/draft-ietf-httpbis-semantics-16
Martin Duke No Objection
Robert Wilton No Objection
[Fixing ballot position.]
Thanks for this document.
Not surprisingly, I don't have many comments on this.
A couple of nits for you to take/leave at your discretion:
This enables caches to _collapse requests_ -
or combine multiple incoming requests into a single forward one upon
a cache miss - thereby reducing load on the origin server and
network.
It wasn't entirely obvious to me what was meant by "single forward one", perhaps this could be clarified.
4.1. Calculating Cache Keys with Vary
The section title looks incomplete, possible something like "with Vary header field" would read better.
Regards,
Rob
Roman Danyliw No Objection
Thanks to Derek Atkins for the SECDIR review. ** Section 7. It would be worth mentioning that user-agents that have interactive human users such as browsers should provide a means to explicitly purge the contents local cache. ** Section 7. Per “Caches expose additional potential vulnerabilities, since the contents of the cache represent an attractive target for malicious exploitation”, do you mean “expose an additional attack surface” (rather than “potential vulnerability”)? ** Section 7.1. Per “Various attacks might be amplified by being stored in a cache”, this text is vague. Is there a specific amplification tied to given attack being suggested here, or is this meant to suggest that the presence of a malicious payload in a cache seeded by an attacker could reach multiple users? ** Section 7.2. Recommend being clearer on the threat rather than the attack vector (“timing attack”): OLD This is sometimes called "double keying." NEW This is sometimes called "double keying” and provides isolation between cross-origin content.
Zaheduzzaman Sarker No Objection
Thanks for efforts put for this document. I have following comments/questions : * I consider this as editorial fix hence not holding a discuss but I would like to see this addressed. This document uses terminologies defined in section 3 of https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-semantics-16#section-3, for example - user agent, client. However, it does not refer to the the semantics doc. I think it must refer to the section 3 of semantic document. * Section 1 : - Is impossible to add a reference to HTTP in the intro? - it says - "A cache stores cacheable responses to reduce the response time and network bandwidth consumption on future equivalent requests. Any client or server MAY use a cache, though not when acting as a tunnel." I think the case "when action as a tunnel" need to be described here to help understanding the context better. The whole tunneling thing came without any prior discussion and the use case is not clearly stated in the entire document. * Section 1.3: this "canned string" can be made more verbose to increase the understanding of the note. * Section 5.2.3: it felt like the readers are expected to know about "cache extension token", that might not always be the case hence please define it or describe it inline in the section.
Éric Vyncke No Objection
(Benjamin Kaduk; former steering group member) No Objection
I made a PR with some editorial suggestions at https://github.com/httpwg/http-core/pull/874 . Section 1.3 negative integer range. If a cache receives a delta-seconds value greater than the greatest integer it can represent, or if any of its subsequent calculations overflows, the cache MUST consider the value to be 2147483648 (2^31) or the greatest positive integer it can conveniently represent. Is that a free choice, MIN, or MAX? Section 3.1 Caches MAY either store trailer fields separate from header fields, or discard them. Caches MUST NOT combine trailer fields with header fields. IIRC, recipients are allowed to merge trailer fields into header fields in some situations (e.g., if explicitly allowed by the field definition). I'm not entirely sure how that allowance is intended to interact with this directive (perhaps that generic-recipient merging has already occurred before this point?). Section 4 A cache that does not have a clock available MUST NOT use stored responses without revalidating them upon every use. (Are we using the same qualifications for what counts as a clock as specified in §10.2.2 of -semantics?) Section 5.2.2.2 The "must-revalidate" response directive indicates that once the response has become stale, a cache MUST NOT reuse that response to satisfy another request until it has been successfully validated by the origin, as defined by Section 4.3. [...] The must-revalidate directive also permits a shared cache to reuse a response to a request containing an Authorization header field (Section 11.6.2 of [Semantics]), subject to the above requirement on revalidation (Section 3.5). It seems like the combination of these two behaviors would allow a shared cache to reuse a response to a request containing an Authorization header field without revalidation, provided it does so before the response has become stale. That seems surprising to me, though it's hard to pin down exactly why. NITS Section 4.2.3 A response's age can be calculated in two entirely independent ways: Just to confirm: this is something that could be said to be the "intrinsic age" or "initial age" of the response, corresponding to the age at the time it was generated/received, as distinct from the age at the time of the calculation? I wonder if adding an adjective would help clarify that. Appendix B The "public" and "private" cache directives were clarified, so that they do not make responses reusable under any condition. (Section 5.2.2) I'm having a hard time figuring out what change this refers to.
(Martin Vigoureux; former steering group member) No Objection