httpd-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm MacCarthaigh <>
Subject Re: svn commit: r329388 - in /httpd/httpd/trunk/docs/manual: caching.xml mod/mod_cache.xml
Date Sat, 29 Oct 2005 19:00:23 GMT
On Sat, Oct 29, 2005 at 01:33:08PM -0500, William A. Rowe, Jr. wrote:
> >+      using the <directive module="mod_cache">CacheDisable</directive>
> >+      directive, or <module>mod_expires</module>. Left unchecked,
> >+      <module>mod_cache</module> - very much like a reverse proxy -
> >cache
> >+      the content when served and then serve it to any client, on any IP
> >+      address.</p>        
> You don't mean reverse proxy, you mean forward proxy (e.g. AOL or other
> intermediate ISP proxies.) 

I did mean reverse proxy. Running mod_cache is bit like having a built
in reverse proxy. Or at least that's what the security model looks like.
Though it might be more re-assuring to put in more familiar terms for

> To this, you can add the point
>   This is no different than a user requesting a resource from this server
>   through a proxy such as AOL, and having the next user to request it also
>   be served the same content, if cache controls are not employed.

Personally, I'd disagree with that statement. Administrators are very
used to the idea that proxies out there on the big bad internet will
display that behaviour, and they can easily take that into account.

It's pretty unlikely that administrators are allowing access from large
parts of the internet, but disallowing from others based on IP address.
Far more common is that they are permitting access to a small group of
hosts they know not to be proxies, or to small list of trusted networks.

The directives:

	Allow from
	Deny from all

are a perfectly reasonable thing to have in a configuration and expect
it to work. mod_cache breaks this reasonable configuration, badly. It
does so much more in a manner similar to a reverse proxy, administrators
may be more familiar with this.

Trying to make this problem seem like something which would have occured
anyway, due to standard forward proxy behaviour, and really that the
admin should have been more careful, is disingenous - and doesn't go far
enough to warning the admin about this broken behaviour.

Though on that front, I still think configure time, and run time
warnings in the log are appropriate for the current behaviour.

> Speaking of which, why recommend mod_cache instead of promoting the HTTP
> protocol itself to solve this problem correctly?

How? do you mean by setting "Vary: *"? not using mod_cache at all?

Colm MacCárthaigh                        Public Key:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message