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 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, is where
On Wed, Nov 02, 2005 at 03:08:47PM -0500, Joshua Slive 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 :/
Sure, but in truth, apache configuration is really complex and deny
On Thu, Nov 03, 2005 at 03:27:43PM +, Joe Orton wrote:
Agreed, and I don't see why this is a showstopper either if this has
been the behaviour of mod_cache forever anyway. showstopper ===
regression
I've taken this out of the show-stopper section, I'll just live with
documentation as a
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
On Sat, Oct 29, 2005 at 09:09:46PM -0700, Paul Querna wrote:
2.1.9-Beta is available from:
http://people.apache.org/~pquerna/dev/httpd-2.1.9/
Please test and vote on releasing 2.1.9 as BETA.
+1 for beta, manual testing + httpd-test passes on all-the-Linuxes here.
Thanks for RMing!
joe
On Sat, Oct 29, 2005 at 09:09:46PM -0700, Paul Querna wrote:
2.1.9-Beta is available from:
http://people.apache.org/~pquerna/dev/httpd-2.1.9/
Please test and vote on releasing 2.1.9 as BETA.
+1 for beta, but some things that would apply to GA;
Doing a complete fresh install from tarball I
On Wed, Nov 02, 2005 at 10:25:54AM +, Colm MacCarthaigh wrote:
Doing a complete fresh install from tarball I got caught out by the
largefile support. Although we no longer need any magic CFLAGS for httpd
itself to handle 2GB files, we do for sendfile for to work
- at least on my platform
On Wed, Nov 02, 2005 at 11:21:18AM +, Joe Orton wrote:
On Wed, Nov 02, 2005 at 10:44:02AM +, Colm MacCarthaigh wrote:
On Wed, Nov 02, 2005 at 10:33:50AM +, Joe Orton wrote:
This sounds very confused. On 64-bit platforms there are never any
magic CFLAGS needed, no
On Wed, Nov 02, 2005 at 11:31:26AM +, Colm MacCarthaigh wrote:
I think you're right, and I think I've found the source of the problem:
apr's network_io/unix/sendrecv.c has:
#if APR_HAS_LARGE_FILES defined(HAVE_SENDFILE64)
apr_off_t off = *offset;
#define sendfile
On Wed, Nov 02, 2005 at 11:38:17AM +, Joe Orton wrote:
and it's the latter branch that gets trigged on IA64
How have you managed to get SIZEOF_OFF_T == 4 as true on IA64?
Hmmm, no, it's 8. As is size_t. I'm going back to scratch at looking at
what's up with gdb.
--
Colm MacCárthaigh
On Wed, Nov 02, 2005 at 11:49:15AM +, Colm MacCarthaigh wrote:
On Wed, Nov 02, 2005 at 11:38:17AM +, Joe Orton wrote:
and it's the latter branch that gets trigged on IA64
How have you managed to get SIZEOF_OFF_T == 4 as true on IA64?
Hmmm, no, it's 8. As is size_t. I'm going
On Wed, Nov 02, 2005 at 01:13:41PM +, Colm MacCarthaigh wrote:
On Wed, Nov 02, 2005 at 11:49:15AM +, Colm MacCarthaigh wrote:
On Wed, Nov 02, 2005 at 11:38:17AM +, Joe Orton wrote:
and it's the latter branch that gets trigged on IA64
How have you managed to get
On Wed, Nov 02, 2005 at 01:34:56PM +, Joe Orton wrote:
Seems to work OK for me with RHEL4/IA64 (2.6.9-22.0.1.EL) with my normal
sendfile test app over loopback.
open(6G.sparse, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0664, st_size=6442450945, ...}) = 0
sendfile(1, 3, [0],
On Wed, Nov 02, 2005 at 02:39:12PM +, Colm MacCarthaigh wrote:
On Wed, Nov 02, 2005 at 01:34:56PM +, Joe Orton wrote:
Seems to work OK for me with RHEL4/IA64 (2.6.9-22.0.1.EL) with my normal
sendfile test app over loopback.
open(6G.sparse, O_RDONLY) = 3
fstat(3,
On Wed, Nov 02, 2005 at 02:50:55PM +, Joe Orton wrote:
Really I don't think it's right to change the code at all to try to
cope with the Nth latest sendfile is broken if... issue. Just
EnableSendfile off as should be default.
Definitely not the preferred option in my case, don't know how
Colm MacCarthaigh wrote:
As a reminder, if you know of any issues you consider a SHOW STOPPER for
a 2.2.0 stable release, please add them to the branches/2.2.x STATUS file.
I'm tempted to suggest the mod_cache Vs mod_authz_host as a
show-stopper, but since this is going nowhere fast and the
On 11/02/2005 11:25 AM, Colm MacCarthaigh wrote:
On Sat, Oct 29, 2005 at 09:09:46PM -0700, Paul Querna wrote:
[..cut..]
As a reminder, if you know of any issues you consider a SHOW STOPPER for
a 2.2.0 stable release, please add them to the branches/2.2.x STATUS file.
I'm tempted to
On Wed, Nov 02, 2005 at 01:10:09PM -0600, William A. Rowe, Jr. wrote:
Well if you see only one way to fix it, yes,
The only viable way anyway. I've been looking at this for a few months,
since I first reported to [EMAIL PROTECTED] (still waiting on a
response) and have tried to construct the
On Wed, Nov 02, 2005 at 08:41:18PM +0100, Ruediger Pluem wrote:
I do not regard this as a showstopper since we only have an admittedly
serious security problem in a *specific* configuration. I think it is
enough to add a big warning to the mod_cache documentation that
protecting cached
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 :/
Sure, but in truth, apache configuration is really complex and deny
from all doesn't always really mean what it says.
This
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 :/
The question though, is where can Deny from all be expected to work?
Certainly not in Directory /foo - the cached entity no longer lives
--On November 2, 2005 7:46:10 PM + Colm MacCarthaigh [EMAIL PROTECTED]
wrote:
The only viable way anyway. I've been looking at this for a few months,
since I first reported to [EMAIL PROTECTED] (still waiting on a
response) and have tried to construct the logic on the authz side, but
Um,
söndagen den 30 oktober 2005 05.09 skrev Paul Querna:
2.1.9-Beta is available from:
http://people.apache.org/~pquerna/dev/httpd-2.1.9/
Please test and vote on releasing 2.1.9 as BETA.
As a reminder, if you know of any issues you consider a SHOW STOPPER for
a 2.2.0 stable release, please add
+1 NetWare
Brad
On 10/29/2005 at 10:09:46 pm, in message
[EMAIL PROTECTED],
[EMAIL PROTECTED] wrote:
2.1.9-Beta is available from:
http://people.apache.org/~pquerna/dev/httpd-2.1.9/
Please test and vote on releasing 2.1.9 as BETA.
As a reminder, if you know of any issues you consider a
On Sat, Oct 29, 2005 at 09:09:46PM -0700, Paul Querna wrote:
2.1.9-Beta is available from:
http://people.apache.org/~pquerna/dev/httpd-2.1.9/
Please test and vote on releasing 2.1.9 as BETA.
+1 for beta.
Passes httpd-test on Ubuntu breezy/ppc. -- justin
On Sun, Oct 30, 2005 at 10:14:29AM -0600, William A. Rowe, Jr. wrote:
They persist on /trunk/ if anyone wants to revisit them. In the interim,
they can simply be blasted on /branches/2.1.x/ - no?
Yes, that is the plan I think we agreed on. -- justin
There is a semi-known issue with the balancer code which mistakenly
does a case-insensitive match on worker and URL. I have a patch
that will be applied today. Not a show-stopper, IMO, but
something that will need to be fixed :)
On Oct 30, 2005, at 12:09 AM, Paul Querna wrote:
2.1.9-Beta is
On Sunday 30 October 2005 04:09, Paul Querna wrote:
2.1.9-Beta is available from:
http://people.apache.org/~pquerna/dev/httpd-2.1.9/
Please test and vote on releasing 2.1.9 as BETA.
compiling
As a reminder, if you know of any issues you consider a SHOW STOPPER for
a 2.2.0 stable
Nick Kew wrote:
Someone still needs to sort out experimental MPMs, and especially purge
perchild, as it tantalises the users so.
AFAICT leader and threadpool are also dead, and event is a potential
candidate for stable, yesno?
They persist on /trunk/ if anyone wants to revisit them. In the
2.1.9-Beta is available from:
http://people.apache.org/~pquerna/dev/httpd-2.1.9/
Please test and vote on releasing 2.1.9 as BETA.
As a reminder, if you know of any issues you consider a SHOW STOPPER for
a 2.2.0 stable release, please add them to the branches/2.2.x STATUS file.
Thanks,
Paul
67 matches
Mail list logo
