- From: Adrien de Croy <adrien@qbik.com>
- Date: Fri, 16 Nov 2007 09:46:52 +1300
- To: Henrik Nordstrom <henrik@henriknordstrom.net>
- CC: Jamie Lokier <jamie@shareable.org>, 'HTTP Working Group' <ietf-http-wg@w3.org>
Henrik Nordstrom wrote: > On tor, 2007-11-15 at 08:51 +0000, Jamie Lokier wrote: > > >> What about whitespace differences (e.g. leading/trailing whitespace, >> whitespace following the header name colon), multi-line breaks, and >> multiple occurrences of the same header? >> >> Does exact means _exactly_ in all those respects, or is it acceptable >> for a cache to canonicalise certain things, like converting multiple >> occurences of a header to a single header by joining with ", " (or >> ","), converting multi-line headers to single-line, and stripping >> leading/trailing whitespace from the header value? >> > > Ofcourse there is some canonisation taking place, you can't compare two > sets of headers otherwise as the LWS and list rules allows the exact > same thing to be transmitted in many ways.. But there is no knowledge of > the meaning of any of the headers involved in the process. > If we don't take into account any meaning of headers, we lose many opportunities to cache. E.g. if an original request for something contained an Accept-Language header specifying many acceptable languages, the response comes back with one of those languages. If a subsequent request comes in which will accept the language that is cached, should that be served back or not? I guess there are difficulties there where for one request it was the preferred language and for another it was a less-preferred language. In which case how would you compare Accept-Language tags? You'd need to compare them as a list with q values. Or would you do it so that if the q value was 1 in the original request and subsequent request then its ok to return that one?: > The process is spelled out in quite detail in 13.2 Caching Negotiated > Documents, with very little room for error other than implementation > bugs. That's provided one cares to read 13.2 before jumping to > conclusions about how this should work. > > Please note that in case of Vary request headers compare it's safe to > err on the cautious side and get false "Vary request" misses. So if you > optimize by doing a string literal compare instead of exact value then > things will still work, just not optimally so.. > > Regards > Henrik > -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
Received on Thursday, 15 November 2007 20:46:21 UTC