Re: Mohamed Boucadair's No Objection on draft-ietf-httpbis-cache-groups-05: (with COMMENT)

Hi Mohammed,

Thank you for the feedback. Responses below; note that I generally incorporate typographical, grammar, and word choice changes at the RFC Editor stage, as they are authoritative on those matters.


> On 18 Apr 2025, at 10:44 pm, Mohamed Boucadair via Datatracker <noreply@ietf.org> wrote:
[...]

> # Same origin
> 
> CURRENT:
>   These mechanisms operate within a single cache, across the stored
>   responses associated with a single origin server .
> 
> Do we need to say how that "single origin server" is identified?

This is formally specified under "Identifying Grouped Responses".

> # Mention the section where to look at
> 
> CURRENT:
>   The Cache-Groups HTTP Response Header is a List of Strings
>   [STRUCTURED-FIELDS].
> 
> and
> 
> CURRENT:
>   The Cache-Group-Invalidation response header field is a List of
>   Strings [STRUCTURED-FIELDS].
> 
> Please add a reference to the exact section to look at.
> 
> As we don’t have a clear reference, I don't know whether we allow empty values?
> Same value repeated several times? upper case, etc.

Done.

> # Parameters
> 
> CURRENT:
>   The ordering of members is not significant.  Unrecognised Parameters
>   MUST be ignored.
> 
> Which parameters?

'Parameter' is a defined term in Structured Fields.

> Also, shouldn’t the validation be based on RFC8941 to avoid redundant
> behaviors? That is, do we need this MUST?

Structured Fields discourages specifications from disallowing Parameters, but does not preclude it (see Section 2.2). 

> # Lack of reasoning
> 
> CURRENT:
>   Implementations MUST support at least 32 groups in a field value ,
>   with up to at least 32 characters in each member.  Note that generic
>   limitations on HTTP field lengths may constrain the size of this
>   field value in practice.
> 
> and
> 
> CURRENT:
>   Implementations MUST support at least 32 groups in a field value,
>   with up to at least 32 characters in each member.  Note that generic
>   limitations on HTTP field lengths may constrain the size of this
>   field value in practice.
> 
> What is the rationale for picking these values?

See discussion starting at:
  https://lists.w3.org/Archives/Public/ietf-http-wg/2025JanMar/0206.html

In general we avoid documenting rationale for choices in specifications, as that would greatly expand their size and make them less useable to implementers.

> What is currently supported by existing implementations?

Implementations are just emerging, but previous practice was to support many more (as discussed in the thread linked above).

> Can this be configurable? How one can retrieve what is supported by a given implementation?

No, and you can't. The point here is to support a floor for interoperability.

> # Comparison logic
> 
> CURRENT:
>   1.  They both contain a Cache-Groups response header field that
>       contains the same String (in any position in the List), when
>       compared character-by-character .
> 
> Is the comparison case-sensitive? Or do we rely on rfc8941 for these matters,
> e.g., to prevent upper case to be used in a list item?

Changed to explicitly specify case sensitivity.

> # Reasoning again
> 
> CURRENT:
>   A cache that receives a Cache-Group-Invalidation header field on a
>   response to an unsafe request MAY invalidate any stored responses
>   that share groups (per Section 2.1) with any of the listed groups.
> 
> What is the rationale for the MAY here?

We can't place new MUST-level requirements on caches, of which there is an unknowable number of deployments existent. This is an optional extension, not something that you can rely upon.

> # Interaction with proxies
> 
> How this mechanism interacts with proxies? Are those allowed to inject/alter
> what is set by a server?
> 
> May be adding a reference where such «generic» matters are covered would be
> useful here.

It depends on the deployment of the proxy; if it's acting on behalf of the origin server or user, this is reasonable.

This is a subtle issue that's out of the scope of this specification; it's not specified explicitly anywhere, but is widely understood in HTTP.

> # Management
> 
> CURRENT:
>   (sometimes referred to as "shared hosting") might allow one party to
>   group its resources with those of others, or to send signals which
>   have side effects upon them.
> 
> How that is managed by a "party" in practice? Is it a configuration action?

The next paragraph explains how:

> Shared hosts that wish to mitigate these risks can control access to the header fields defined in this specification.


> # Cascaded effect
> 
> If we have an entry that belongs to A/B, another that belongs to B/C, and a
> third to C/D. If A group is invalidated, this will impact the second entry per
> the rules in 2.2.1. However, does this impact the third one as well is it
> shares a group with the second invalidated one?

This is an interesting question. It's reasonable to assume that *any* invalidation (including that triggered by a group invalidation) is eligible, but some implementers may reasonable wish to avoid allowing such a 'cascade' for efficiency reasons.

I tend to think that we should explicitly specify that an invalidation triggered by a group invalidation does NOT trigger group invalidations itself; i.e., there is no "cascading." 

What do others think?

Cheers,

--
Mark Nottingham   https://www.mnot.net/

Received on Sunday, 20 April 2025 08:39:53 UTC