Re: What is The logic of Vary Headers cachiness?

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
Received on Thu Jul 25 2013 - 20:37:24 MDT