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

--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii

Oh well. And Alex Rousskov writes:
 -
 - 0) As far as I understand, Ingrid and you want the document to be cachable,
 - but "servable" only to a restricted set of users. [...] This restriction
 - smells more like access controls to me.

It _is_ an access control, but specified by the headers for the particular
document. I have squid up as a non-transparent (same machine) httpd
accelerator. The server sees hits from the same machine, so the server
cannot enforce per-file access controls.

On a larger scale, we're slowly building up a campus cache system. If
I wish to restrict a document to *.ufl.edu but some admin gives the
outside ISP he uses access to his cache... No, there isn't a perfect
solution, but this would at least help.

Of course, I have enough people imploding about no longer knowing the
IPs of who's hitting their pages (like they really did before) that I'll
probably be forced to ditch the accelerator. sigh...

 - I am not sure Cache-Control header field is a proper place for that

It instructs the cache. Thus, it's a cache control.

 - Please double check the HTTP/1.1 specs, but I think it clearly indicates
 - that Cache-Control is used for things _other_ than access controls (mostly
 - limiting storing and/or caching of an object).

Section 13.1.3 of the 13 March draft:
  In some cases, a server or client may need to provide explicit directives
  to the HTTP caches. We use the Cache-Control header for this purpose.

It's an explicit directive to a cache. ;) Access controls are not,
however, listed in the possible uses. It'd fall into the cache
extension part.

 - 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. 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.

 - Finally, if the set of the documents you want to attach "Access-restricted"
 - directives to is small, consider making them non-cachable.

Non-cacheable doesn't help me. Our server still sees the hits from
itself. And setting up the accelerator on another machine is not an
option for us at the moment. I _might_ be able to pull off some tricks
with multiple virtual interfaces to make it transparent, but that's
getting into much heavier magic than I want to use. (Read: I can read
the squid code to find problems. I at least vaguely understand it. I've
never dealt with IP-forwarding code.)

And non-cacheable also doesn't help if the neighbor has access but only
some of that neighbor's clients have access, as you pointed out.

 - 1) Seems like an 'Access-restricted="Domain:"' directive will be not-so-easy
 - to implement because it requires a [reverse] DNS lookup on client's IP.

Nope, it's not easy. I wouldn't use it. DNS is hardly a good way to
restrict access, anyways. And it's worse in a cache; it'll force a
potentially long DNS lookup. I'm much more interested in restricting to
(or from) a set of IP/netmask pairs.

I'd probably also allow an ACL: extension that can specify a squid
ACL by name. Non-portable, but pretty useful internally.

 - 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.

 - 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...

 - HttpReplies are using it for a long time already. HttpRequests will
 - probably start using it in b21.

Peachy.

 - 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.

 - Maybe you can ask this question on HTTP discussion list?

I would, but I'm considering implementing it _now_ and fixing it later.
And I'm on way too many lists / projects as it is.

Basically, I don't like the idea of IP/DNS restrictions. I think
they're silly, particularly in our case (distance education, anyone?).
I've been asked to ensure they're possible, however.

The other possibility, at least for us, is to run a virtual host
named www-internal (or something like that) and redirect all URLs
with a magic name to it. Maybe that's better, over-all. hmm...
Access controls are inherently local, and I believe that's the basis
for your argument... The draft's proposal scales better, though.

Jason

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