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 . 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.