Justin Erenkrantz wrote:
On Tue, Nov 08, 2005 at 07:48:07AM +0100, Ruediger Pluem wrote:
So do you think that there is a todo for mod_authz_host to add such things
or should this be left to the administrator who can of course use
mod_headers in the first case to add Cache-Control: private?
On Tue, Nov 08, 2005 at 12:54:18PM -0500, Joshua Slive wrote:
1. Order Allow,Deny
Allow from all
2. Order Deny,Allow
Allow from all
3. Order Deny,Allow
The difference between the three only becomes important if you add more
Allow/Deny directives.
o.k., is the following
Colm MacCarthaigh wrote:
if single-allow-from-all no-deny-rules:
no-header;
else
header;
I think that is probably reasonable and would catch 99.5% of real
configs. There is a silly case that I didn't mention:
Order deny,allow
Deny from all
On 11/08/2005 01:36 AM, Roy T. Fielding wrote:
On Nov 7, 2005, at 3:03 PM, Ruediger Pluem wrote:
[..cut..]
but the next request for this (fresh) resource will not check the
access control and
deliver it to any client, regardless of the IP. Correct?
Many thanks for sorting my
Ruediger Pluem wrote:
http://httpd.apache.org/docs/2.0/mod/mod_proxy.html#access
suggests to secure a forward proxy by using mod_authz_host. Currently the
advice should be the
opposite: Yes, secure your forward proxy, but do *not* do this with
mod_authz_host as it
does not work as
On 11/08/2005 10:15 PM, Joshua Slive wrote:
Ruediger Pluem wrote:
[..cut..]
Has anyone actually tested this? Is it true that there is no way to run
a host-restricted cached proxy? That would be really lame.
I tested only with 2.0.55 today. But given the fact that this part of
On Monday 07 November 2005 03:26, Paul Querna wrote:
Cache-control: private
is what should be added for any resource under access control.
I'd prefer something a little less drastic, like 'faking' a header out
of remote-ip.
I still like making it admin configurable. Allowing the admin to
On Nov 7, 2005, at 2:06 AM, Nick Kew wrote:
On Monday 07 November 2005 03:26, Paul Querna wrote:
Cache-control: private
is what should be added for any resource under access control.
I'd prefer something a little less drastic, like 'faking' a header out
of remote-ip.
Why? All you
On 11/07/2005 07:27 PM, Roy T. Fielding wrote:
On Nov 7, 2005, at 2:06 AM, Nick Kew wrote:
On Monday 07 November 2005 03:26, Paul Querna wrote:
Cache-control: private
is what should be added for any resource under access control.
I'd prefer something a little less drastic, like
Ruediger Pluem wrote:
I agree that there are many situation where it does not make sense to cache
things under access
control, but there are ones where it makes sense.
e.g. If you create a forward proxy with httpd that should use caching and that
only
a limited number of clients on your LAN
Graham Leggett wrote:
Ruediger Pluem wrote:
I agree that there are many situation where it does not make sense to
cache things under access
control, but there are ones where it makes sense.
e.g. If you create a forward proxy with httpd that should use caching
and that only
a limited
On Nov 7, 2005, at 1:01 PM, Paul Querna wrote:
If there is a compelling reason to support not adding Cache-Control:
private to authenticated requests, then it's definitely an option,
but I
think we should default to the safe option for now.
The compelling reason is that this implies that
On 11/07/2005 09:48 PM, Graham Leggett wrote:
Ruediger Pluem wrote:
I agree that there are many situation where it does not make sense to
cache things under access
control, but there are ones where it makes sense.
e.g. If you create a forward proxy with httpd that should use caching
and
On Monday 07 November 2005 21:10, Roy T. Fielding wrote:
On Nov 7, 2005, at 1:01 PM, Paul Querna wrote:
If there is a compelling reason to support not adding Cache-Control:
private to authenticated requests, then it's definitely an option,
but I
think we should default to the safe option
On Mon, Nov 07, 2005 at 09:28:54PM +, Nick Kew wrote:
No, you should be setting Vary: * if the content varies. That is
also required by HTTP.
That applies if it varies by some request header.
Vary: * means that how the content varies in unspecified, and section
12.1 of RFC2616
On 11/07/2005 10:31 PM, Justin Erenkrantz wrote:
--On November 7, 2005 10:16:34 PM +0100 Ruediger Pluem
[EMAIL PROTECTED] wrote:
[..cut..]
The problem is that without Cache-Control: private, any downstream cache
would have the exact same problem. There's no way for it to know that
the
--On November 7, 2005 11:09:05 PM +0100 Ruediger Pluem [EMAIL PROTECTED]
wrote:
must be HTTP compliant, but there should be possibilties (and there
already are) to
break this compliance with explicit configuration options to get some
things working.
Yes, CacheStorePrivate will do this. --
On Nov 7, 2005, at 2:09 PM, Ruediger Pluem wrote:
The problem is that without Cache-Control: private, any downstream
cache
would have the exact same problem. There's no way for it to know that
the response differs based on IPs unless the Origin says so. --
justin
This is true. But in the
On 11/07/2005 11:30 PM, Roy T. Fielding wrote:
On Nov 7, 2005, at 2:09 PM, Ruediger Pluem wrote:
The problem is that without Cache-Control: private, any downstream cache
would have the exact same problem. There's no way for it to know that
the response differs based on IPs unless the
On 11/07/2005 10:10 PM, Roy T. Fielding wrote:
On Nov 7, 2005, at 1:01 PM, Paul Querna wrote:
If there is a compelling reason to support not adding Cache-Control:
private to authenticated requests, then it's definitely an option, but I
think we should default to the safe option for now.
Ruediger Pluem wrote:
If I have a forward proxy to which I limit access via IP based access control
I should add Cache-Control: private to any response I get back from the backend
(either a Remote Proxy or the origin server).
A very important distinction: forward and reverse proxy
On Nov 7, 2005, at 3:03 PM, Ruediger Pluem wrote:
Just checking if I understood things correctly:
If I have a forward proxy to which I limit access via IP based access
control
I should add Cache-Control: private to any response I get back from
the backend
(either a Remote Proxy or the origin
On Nov 7, 2005, at 3:10 PM, Ruediger Pluem wrote:
Not for every page, but if I get it right once you lock out one bad
boy via
deny ipaddress
than it should be sent. AFAIK this not done automatically currently
once you add a deny
directive somewhere. Does this need to be changed?
I can't
On Tue, Nov 08, 2005 at 07:48:07AM +0100, Ruediger Pluem wrote:
So do you think that there is a todo for mod_authz_host to add such things
or should this be left to the administrator who can of course use
mod_headers in the first case to add Cache-Control: private?
It'd be nice if
On Nov 4, 2005, at 10:56 AM, William A. Rowe, Jr. wrote:
It leaves us wondering; how can allow from/deny from n.n.n.n be mapped
to
RFC 2616 semantics, or at least, without running the many server hooks
on
later requests? The only way I can see, is that we should have any
more
explicit allow
Roy T.Fielding wrote:
On Nov 4, 2005, at 10:56 AM, William A. Rowe, Jr. wrote:
It leaves us wondering; how can allow from/deny from n.n.n.n be mapped to
RFC 2616 semantics, or at least, without running the many server hooks on
later requests? The only way I can see, is that we should have
Nick Kew wrote:
I'm not convinced by that either. In fact, I dislike the whole run it in a
quick handler principle - it runs a supertanker through the KISS principle,
and has consequently left us with a cache that never really worked.
Even if we fix this, it's sure to have a high bugrate for
Graham Leggett wrote:
The httpd cache is simply yet another cache in the chain of HTTP/1.1
caches that are typically present when a browser accepts a page from a
website. The authentication issue is handled by RFC2616 already, and as
long as httpd mod_cache conforms to the correct headers
Joshua Slive wrote:
I haven't looked carefully at the code, but I don't believe
protocol-level things like the force-response-1.0 variable are stored in
the cache.
If it's a global setenvif variable (runs is post-read, before
quick-handler), then these adjustments work, because
Joshua Slive said:
I agree with you about 90%. The problem is that there are a very few
things that aren't accounted for in standard HTTP caching rules. One
example is Varying access by client IP address.
I can't see how you could have any meaningful caching at all if the
content is varied
I almost tried to snip the comments below in my reply, and there was nothing
I could clip out - thank you Graham for explaining so clearly the entire design
principals of how and why mod_proxy does exactly what it does.
It leaves us wondering; how can allow from/deny from n.n.n.n be mapped to
Graham Leggett wrote:
Joshua Slive said:
I agree with you about 90%. The problem is that there are a very few
things that aren't accounted for in standard HTTP caching rules. One
example is Varying access by client IP address.
I can't see how you could have any meaningful caching at all
On 11/04/2005 08:20 PM, Joshua Slive wrote:
Graham Leggett wrote:
[..cut..]
In this case you'd probably not use the cache at all for this part of the
URL space.
This is the case we've been discussing where someone wishes to, for
example, restrict a reverse proxy to a particular
On 11/03/2005 11:01 AM, Nick Kew wrote:
On Wednesday 02 November 2005 20:26, William A. Rowe, Jr. wrote:
Colm MacCarthaigh wrote:
[..cut..]
Certainly not in Directory /foo - the cached entity no longer lives
there.
I disagree. If it came from there originally, then that's where it
--On November 3, 2005 8:44:02 PM +0100 Ruediger Pluem [EMAIL PROTECTED]
wrote:
I also agree with this. While I understand the performance benefits from
the developer perspective, I fear the confusion from the user and
administrators perspective. Having a clear configuration is not only
about
Justin Erenkrantz wrote:
--On November 3, 2005 8:44:02 PM +0100 Ruediger Pluem
[EMAIL PROTECTED] wrote:
I also agree with this. While I understand the performance benefits from
the developer perspective, I fear the confusion from the user and
administrators perspective. Having a clear
Justin Erenkrantz wrote:
In my performance analyses that I did when redoing mod_cache last year,
a substantial part of the time in httpd was spent in all of the hooks
prior to the handler. Things like BrowserMatch (which do regex's) are
ridiculously expensive.
Interesting to think,
On Thu, Nov 03, 2005 at 08:03:56PM -0500, Joshua Slive wrote:
it seems there is no way to work around client protocol problems. (Just
sending Vary: User-Agent wouldn't fix the problem, because when the user
agent matched a cached variant, the protocol adjustments still wouldn't
be
38 matches
Mail list logo
