On 07/25/2013 09:53 PM, Henrik Nordström wrote: > Imho the Key header is a dream. But sure having support for it as well > would be nice. But it is not an escape from supporting Vary. > > The issue Key tries to address isn't really that big, if ignoring > Cookie. And it's very unlikely site owners manages to specify Key > correctly, they already have a hard time even doing Vary right. > > Even the most basic Accept example in the Key draft is flawed. The > example will also match "Accept: text/html;q=0", plus completely fails > in representing quality at all. I.e. consider two clients one preferring > HTML one preferring plain text, but both can handle both if absolutely > required (i.e. the usual case for Accept*). > > Regards > Henrik
So basically we are handling the request with basic hope that the site owner does not try to exploit the cache while honouring RFCs and admins. The Accept and Accept-Encoding cases are pretty strong also ETAG. Which I have seen ETAG IMS and seems reasonable to me. The main problem with ETAG from what I have seen and I need to read more about ETAG, is.. couple mirrors ETAG should be the same for all servers objects in the level of HASH like.. which is not.. an example: # curl -I "http://fedora.mirror.nexicom.net/linux/releases/19/Live/x86_64/Fedora-Live-KDE-x86_64-19-1.iso"; HTTP/1.1 200 OK Date: Thu, 25 Jul 2013 20:31:37 GMT Server: Apache/2.2.22 (Debian) Last-Modified: Thu, 27 Jun 2013 17:58:33 GMT ETag: "b5b8002-36e00000-4e02682b32440" Accept-Ranges: bytes Content-Length: 920649728 Content-Type: application/x-iso9660-image # curl -I "http://ftp.linux.cz/pub/linux/fedora/linux/releases/19/Live/x86_64/Fedora-Live-KDE-x86_64-19-1.iso"; HTTP/1.1 200 OK Date: Thu, 25 Jul 2013 20:32:55 GMT Server: Apache/2.2.22 (Fedora) Last-Modified: Thu, 27 Jun 2013 17:58:33 GMT ETag: "7ed0a4-36e00000-4e02682b32440" Accept-Ranges: bytes Content-Length: 920649728 Content-Type: application/octet-stream So even the content type is not the same... they both run apache both run 2.2.22 and they both have right LM headers but they both have different ETAG which is a bit weird but not unacceptable.. Eventually if we do create a temporary object in cache_dir and use fixed size or max size for specific headers we can allocate them first and later on update them if needed. we can use a fixed size like "arrays" of size like the TLV that we can try to assume that if the request has specific headers the object will have a metadata and header size that can be updated. I do hope and know that httpbits tries to make all of the above true.(reading) Eliezer
