Cache-Control vs new header field, was: Working Group Last Call: draft-ietf-httpbis-no-vary-search

Am 14.10.2025 um 16:34 schrieb Julian Reschke:
> ...
> Speaking of which, RFC 9111 states in <https://greenbytes.de/tech/specs/ 
> rfc9111.html#rfc.section.4.p.3>:
> 
>  > Note that a cache extension can override any of the requirements 
> listed; see Section 5.2.3.
> 
> which is about Cache-Control.
> 
> Was it ever considered to use Cache-Control here? (yes, I understand the 
> parsing issues) ... in any case, a short statement why not might be good.
> ...

...so:

It's evident that this could have been a Cache-Control response 
directive 
(https://greenbytes.de/tech/specs/rfc9111.html#cache-response-directive).

Example:

 > No-Vary-Search: params=("utm_source" "utm_medium" "utm_campaign")

(taken from 
<https://www.ietf.org/archive/id/draft-ietf-httpbis-no-vary-search-03.html#section-1>)

That could have been:

Cache-Control: no-vary-on="utm_source utm_medium utm_campaign"

In fact, 
<https://greenbytes.de/tech/specs/rfc9111.html#rfc.section.4.p.3> says:

 > Note that a cache extension can override any of the requirements 
listed; see Section 5.2.3.

...and that points to the description of Cache-Control extension directives.

I'll claim that if I ask myself "why?", other reader probably will think 
the same.

I don't expect that the approach will be changed. In which case we 
should minimally mention this as a design choice/consideration.

So what are the reasons why this is a new field instead of a 
Cache-Control directive?

I can think of some:

1. Cache-Control is already hard to parse (Mark? Data?).
2. Structured Fields are cool (which they are)
3. This operates on a higher layer; the HTTP specs do not even define 
what a query parameter is.

(re 1 - if this is the reason, we should write that down somewhere; 
either in a RFC9111bis)

The strongest point IMHO is 3.

Feedback appreciated,

Julian

Received on Sunday, 18 January 2026 11:29:33 UTC