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 pa
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 expected.
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 m
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 al
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 followin
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?
I
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 mod_authz_
On 11/08/2005 01:55 AM, Roy T. Fielding wrote:
> On Nov 7, 2005, at 3:10 PM, Ruediger Pluem wrote:
>
[..cut..]
>
> I can't remember which directive applies where, but if the
> access control is set to deny all and allow some, where some
> is a locally restricted subset of all, then cache-cont
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 r
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
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 authenticati
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 f
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 unles
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 c
--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 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
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 November 7, 2005 10:16:34 PM +0100 Ruediger Pluem <[EMAIL PROTECTED]>
wrote:
It talks about *single* users. The problems we are facing here are
*groups* of users. So the cache is a shared cache for this group of users
in this case.
The problem is that without Cache-Control: private, any
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
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 c
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 even
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
>>
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 s
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 le
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 accompl
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 ad
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
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 f
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
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 i
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
RFC
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 varie
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
"force-re
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 hand
Justin Erenkrantz wrote:
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 stil
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
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 appli
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, however,
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 c
--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
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 - the cached entity no longer lives
>>there.
>
>
> I disagree. If it came from there originally, then that's where it l
On Wednesday 02 November 2005 20:26, William A. Rowe, Jr. wrote:
> Colm MacCarthaigh wrote:
> > I think the text "Deny from all" is a particularly dangerous thing to
> > have not work as advertised! No matter how well documented :/
Nasty. Is it necessarily a showstopper?
> The question though, i
42 matches
Mail list logo
