Re: I-D Action: draft-ietf-httpbis-no-vary-search-05.txt

[Rory Hewitt <[e-mail]>]

On Mon, Jun 1, 2026 at 8:10 PM Nidhi Jaju <[e-mail]> wrote:

> Hi,
>
> I agree with Tommy that renaming params/except to include/exclude is an
> editorial change. The parsing and processing logic is unchanged, so what
> we're discussing is which strings sit on the wire.
>

I honestly don't get the difference between an editorial change (renaming
field values) and a substantive change. Sure, the underlying processing
logic in the browser is the same, but at some point those names have to be
'fixed' with no further changes to the RFC. Do such things ever get changed
this late in the day, or are they already effectively set in stone anyway?

Each of the proposals has pros and cons. include/exclude reads more
> naturally on its own, but as noted, "exclude" inside a field called
> "No-Vary" is confusing depending on how you parse the field name, since the
> things that are excluded are the ones that don't vary. Cache-Query-Params
> came up as an option to replace No-Vary-Search, but it's not clear that
> there's a significant enough win to justify a rename at this point.
>

I agree that a double-negative is bad, hence my feeling that this header
(which identifies query parameters to use for caching) would be
better-named as Cache-Query-Params...

But since I have been (inaccurately, IMO) accused of bikeshedding, I'm not
going to push it.