Opened 14 years ago

Closed 13 years ago

#147 closed design (fixed)

serving negotiated responses from cache: header-specific canonicalization

Reported by: julian.reschke@… Owned by: mnot@…
Priority: normal Milestone: unassigned
Component: p6-cache Severity: Active WG Document
Keywords: Cc:


Part 6, Section 2.6 currently says:

"The selecting request-headers from two requests are defined to match if and only if the selecting request-headers in the first request can be transformed to the selecting request-headers in the second request by adding or removing linear white space at places where this is allowed by the corresponding ABNF, and/or combining multiple message-header fields with the same field name following the rules about message headers in Section 4.2 of [Part1]." -- <>

Should the matching requirement be relaxed so that it would be ok to use a cached response if the selecting request headers match after canonicalization, such as by treating

Accept-Encoding: gzip


Accept-Encoding: gzip, identity

as 'matching'?

Attachments (1)

i147.diff (2.4 KB) - added by julian.reschke@… 13 years ago.
Proposed patch for part 6.

Download all attachments as: .zip

Change History (6)

comment:2 Changed 13 years ago by henrik@…

If there is rules for how a given request header may be canonicalized and the cache (or related agent) knows about and implement such rules then selection should be after canonicalization, not limited to just whitespace or list combining. And if any such canonicalization is done it's better done on forwarded requests as well, and not just the cached response selection.

But generally a transparent cache should not be doing much of these things.

Additionally the process outlined in p6 "Caching of negotiated resources" isn't too complex for caches to handle for learning the effects of these minor variations, provided the server do return proper ETag values for each resource variant AND know hot to handle If-None-Match...

comment:3 Changed 13 years ago by mnot@…

  • Owner set to mnot@…
  • Priority set to normal


Caches MAY canonicalise header values when they are known to have identical meaning by their specification

Changed 13 years ago by julian.reschke@…

Proposed patch for part 6.

comment:4 Changed 13 years ago by julian.reschke@…

From [771]:

clarify header normalization vs matching request headers (see #147)

comment:5 Changed 13 years ago by mnot@…

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.