Hi Marco, See: https://github.com/httpwg/http-extensions/commit/b3720fdf0 Regarding receiving both headers: ordering of processing shouldn't matter, because HTTP already has invalidation semantics for POST responses; see https://httpwg.org/specs/rfc9111.html#invalidation Cheers and thanks, > On 25 Feb 2025, at 11:57 pm, Marco Tiloca via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Marco Tiloca > Review result: Ready with Nits > > I reviewed this document as part of the Applications and Real-Time (ART) Area > Review Team's ongoing effort to review all IETF documents being processed by > the IESG. These comments were written primarily for the benefit of the ART Area > Directors. Document authors, document editors, and WG Chairs should treat these > comments just like any other IETF Last Call comments. > > Thanks for this document! I believe it is basically ready. > > Please see below a few minor comments. > > Best, > /Marco > > [Section 1] > > * It says: > >> Section 2 introduces a means of describing the relationships between a set > of stored responses in HTTP caches by associating them with one or more > opaque strings. It also describes how caches can use that information to > apply invalidation events to members of a group. > > If I understand correctly: > > * "set" in the first sentence is what "group" means in the second sentence. > > * The "opaque strings" in question are practically the names given to the > groups. > > * If the strings are opaque, I'm not sure how much they are about > "describing" relationships. I suppose that what actually reflects the > relationships is the group memberships of the cached responses. > > If the above is correct, a possible rephrasing is: > >> Section 2 introduces a means of describing the relationships between stored > responses in HTTP caches, by associating those responses with one or more > groups that reflect their relationships and that are identified by opaque > strings. It also describes ... > > A rephrasing along the same lines can apply to the abstract too. > > [Section 2.1] > > * It says: > >> to have the same group ... > > I guess it means: > >> to belong to the same group ... > > [Section 3] > > * It says: > >> For example, a POST request that has side effects on two cache groups could > indicate that stored responses associated with either or both of those groups > should be invalidated with: > > I think you mean: > >> For example, following the successful processing of a POST request that has > side effects on two cache groups, the corresponding response could indicate > that ... > > * Even though hardly useful, it seems admitted that: > > * A response includes both the Cache-Groups header field and the > Cache-Group-Invalidation header field; and > > * Both header fields include the same string "foo". > > In that case, is it still entirely up to the cache receiving the headers to > decide whether first associating the response with the group "foo" and then > optionally removing the response from that group, or instead doing vice versa? > > Would a specific processing order be desirable/expected? For example, first > process the Cache-Group-Invalidation header and then the Cache-Groups header, > in case both are present in a response. > > [Nits] > > * Section 1 > --- s/address this issues/address the issues > > * Section 2.1 > --- s/The both/They both > > * Appendix A > > The "Acknowledgements" section is usually an unnumbered section after the > appendices (if any), see RFC 7322. > > > -- Mark Nottingham https://www.mnot.net/ -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
