IETF Last Call Review of draft-ietf-httpbis-no-vary-search-06
review-ietf-httpbis-no-vary-search-06-genart-lc-knodel-2026-07-27-00

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

Document: draft-ietf-httpbis-no-vary-search-??
Reviewer: Mallory Knodel
Review Date: 2026-07-27
IETF LC End Date: 2026-07-28
IESG Telechat date: Not scheduled for a telechat

Summary: This document specifies an HTTP response header field allowing an
origin server to indicate whether and how query parameters in a URL should or
shouldn't be used to retrieve a stored response from a cache. This improves on
ordinary cache matching, in which various inconsequential query components in a
URL prevent reuse of the same stored response. So, this specification allows
for increased efficiency in the use of cached resources, eg more URLs point to
the same resource.

Major issues: None.

Minor issues:

 * The name, raised by others, is unfortunate. "No-Vary-Query" is probably my
 favourite iteration if the authors and implementers would be amenable to a
 change. (Past discussion indicates they're not.) However just to illustrate
 that other keywords that are used in the document better describe behaviour
 ("search" isn't used narratively, ever): key, cache, query, parameter,
 matching, key cache, query parameter, cache matching.

 * The abstract could be longer to describe how the extension is specified, eg
 structured fields, who (origins) for whom (caches), etc.

 * As either a second or final paragraph to the introduction, the reader would
 benefit from a deployment model that describes which intermediaries are the
 implementers (senders, responders), other intermediaries. Perhaps it would
 help to draft this from the perspective of the cache, since I largely agree
 with other reviewers that the document is written primarily from the browser
 perspective and what's missing are the impactful details in the overview for
 caching.

 * The list following Table 1 should be a table that describes the reason that
 the inputs are invalid rather than making the reader solve a puzzle. Some in
 the list are instructive while others are unexplained, eg 5 and 6 would
 ostensibly be invalid for the same reason. Let's just be straight forward, and
 perhaps a bit boring, in service of giving a clear explanation.

 * Security: Others have said this but this section is rather understating the
 risk. Perhaps it's best summarized as potentially exacerbating cache
 configuration security issues that aren't introduced by this field, but
 nonetheless could make things worse. Why not point elsewhere to more robust
 caching configuration guidance but also elaborate in this section a list of
 things to *not* configure here ("because if you are configuring them here you
 are in the wrong place-- stop!")? Plus an additional warnings like,
 "Parameters must not be ignored where a cache hit could bypass processing
 required for safe response reuse, including authorization, users, signatures,
 consent, privacy policy, routing, auditing, revocation, expiry, security
 sensitivity, or others that indicate processing which could be bypassed by a
 cache hit."

 * Privacy: Agree with the author's choice to present the privacy gains with
 this specification. However an errant configuration could expose cached
 content meant for resources with different parameters in a way that could
 violate privacy-- this mistake, while made elsewhere, would be at minimum
 replicated or at maximum actually made worse by this field. Essentially a
 subsection of the security considerations but specifically related to those
 that would impact user privacy.

Nits/editorial comments:

 * Everywhere ensure that all words appear together for: '"No-Vary-Search"
 response header field'. In some places "response" or "header" are left out.
 This inconsistency is confusing to the reader.

 * Briefly explain "cache busting" the first time it is used, since it is a
 term of art in quotations. Maybe, "'Cache busting' refers to changing a query
 parameter in order to create a distinct cache key and force retrieval of a
 newer response."

 * Please give the positive example of key-order in 5.2.1. Table 1 for
 completeness.

 * The parenthetical in the last sentence of Security Considerations is either
 unnecessary or is communicating something in a way that is too difficult to
 understand, "...how they present the (URL, response body) pair, including..."

Thanks a lot for this document.