Hi Mallory, Thank you for the review. I've uploaded a PR to address the comments here: https://github.com/httpwg/http-extensions/pull/3502. Please let me know if you have any additional feedback.
Best regards, Nidhi Jaju On Tue, Jul 28, 2026 at 4:30 AM Mallory Knodel via Datatracker < [email protected]> wrote: > Document: draft-ietf-httpbis-no-vary-search > Title: The No-Vary-Search HTTP Caching Extension > Reviewer: Mallory Knodel > Review result: Ready with Issues > > 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. > >
_______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
