Re: HttpHdrCc & draft-melve-cachecontrol-00.txt...

--MimeMultipartBoundary
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 29 Apr 1998, Jason Riedy wrote:

> - I am not sure Cache-Control header field is a proper place for that
> It instructs the cache. Thus, it's a cache control.

It instructs the proxy. It has nothing to do with _caching_ of documents.
Thus, it is not a cache control :) Cache-control controls caching and
storage, not access permissions, IMHO.
 
> - Also, client IP may not be available if the document is being requested
> - through another proxy (e.g., a close-by peer).
>
> Exactly... The Cache-Control restriction will travel with it. If
> everyone supports it (like I said, not perfect), the other cache will
> then refuse to give it to the client.

My concern is that a cache will not serve it to another [local] _cache_
unless you list all the local caches in "Access-restricted" field.

> It doesn't serve to limit the
> amount of traffic between caches, though. Presumably, if the cache
> has access to the document, at least some of the cache's clients have
> access, so it might not be a total loss.

This implies that all local caches are listed in "Access-restricted" field,
right?

> - 2) Note that with "IP" or "Domain" directive, Squid will have to start
> - loading a cached object from disk first (to get the headers) and only then
> - discover that it cannot serve the object because of the Access-restricted
> - field.
>
> I wouldn't do it that way. I'm looking at somehow storing an ACL or an
> ACL reference in the metadata. I'm not yet positive that this way is
> better, but it makes more sense to me.

Unfortunately, adding memory-resident metadata will increase memory
requirements for Squid. We are trying to keep StoreEntry as small as
possible. People will be very reluctant to increase its size just to support
a new cc directive, IMHO. And I would be against adding a yet another piece
of ifdef-ed code.

> - 3) Please consider deleting "Comma separated lists" option.
>
> I kinda agree, although the comma-separated lists would make it easier
> on my users. Of course, I could just hack Apache to do the right thing
> with this header...

Hmm. Making HTTP easier for users already created all sorts of weird
problems. Not sure we should add one more. :) IMHO, HTTP should be used by
machines and programmers, not human beings. :)
 
> - Again, "Cache-control", IMHO is not a perfect place for the new directive.
>
> I don't think there is a perfect place. Unless there's another extant
> header explicitly to instruct caches, I'd prefer using this one over
> creating a new one. Creating an X-ACL might not be too bad, though.

I would vote for X-Acl or Access-Control. A much cleaner solution, IMHO.
Ingrid (if you are listening), what do you think about moving
"Access-restricted" cc directive to a generic "per-object access control"
header?
 
> I would, but I'm considering implementing it _now_ and fixing it later.

Future Squid hackers will be very "thankful" for that :) Also, if it is
designed badly, other caching proxies may not support it.

Alex.

--MimeMultipartBoundary--
Received on Tue Jul 29 2003 - 13:15:48 MDT