* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ticket #147 (closed design: fixed)

Opened 5 years ago

Last modified 4 years ago

serving negotiated responses from cache: header-specific canonicalization

Reported by: julian.reschke@gmx.de Owned by: mnot@pobox.com
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]." -- <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p6-cache-06.html#rfc.section.2.6>

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'?


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

Change History

comment:2 Changed 5 years ago by henrik@henriknordstrom.net

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 5 years ago by mnot@pobox.com

  • Owner set to mnot@pobox.com
  • Priority set to normal


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

Changed 4 years ago by julian.reschke@gmx.de

Proposed patch for part 6.

comment:4 Changed 4 years ago by julian.reschke@gmx.de

From [771]:

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

comment:5 Changed 4 years ago by mnot@pobox.com

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