Skip to main content

HTTP Caching
draft-ietf-httpbis-cache-19

Yes

Francesca Palombini
Murray Kucherawy

No Objection

Alvaro Retana
John Scudder
Martin Duke
Éric Vyncke
(Martin Vigoureux)

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

Comment (2021-06-17 for -16)
[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

Comment (2021-06-11 for -16)
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

Comment (2021-06-14 for -16)
[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

Comment (2021-06-10 for -16)
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

Comment (2021-06-16 for -16)
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

No Objection (2021-06-16 for -16)
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

No Objection (for -16)