In our proxy, we launch an external helper app the does active health
checking of the origin servers. This is a HEAD request on a configurable
(per origin pool) uri (ie, http://host:port/url/blah). When an origin
passes/fails a given number of checks it is marked up/down. For example,
when an
On Oct 2, 2007, at 5:56 PM, Ruediger Pluem wrote:
Slightly off topic, but this gives me the idea that we could use
OPTIONS * as some kind of ping / health check for pooled connections
in mod_proxy_http before sending a request (at least in the reverse
proxy case before sending a request that
Jim Jagielski wrote:
On Oct 2, 2007, at 5:56 PM, Ruediger Pluem wrote:
Slightly off topic, but this gives me the idea that we could use
OPTIONS * as some kind of ping / health check for pooled connections
in mod_proxy_http before sending a request (at least in the reverse
proxy case before
On Wed, 03 Oct 2007 15:04:52 +0200
Rainer Jung [EMAIL PROTECTED] wrote:
It would be nice to have the health check running asynchronously from
the normal request handling (error detection for idle connections,
before requests fail). Even more important, the recovery test could
be done
On Oct 1, 2007, at 4:07 PM, William A. Rowe, Jr. wrote:
Jim Jagielski wrote:
But, as I read it, the '*' in OPTIONS * does not really
mean a Location *... in other words, it's not a URI per se.
OPTIONS * asks for the capabilities of the server itself,
independent of URI... At least, that's
Comments?:
Index: modules/http/http_core.c
===
--- modules/http/http_core.c(revision 581205)
+++ modules/http/http_core.c(working copy)
@@ -234,6 +234,24 @@
return OK;
}
+static int http_send_options(request_rec *r)
+{
On 10/02/2007 03:16 PM, Jim Jagielski wrote:
Comments?:
Looks fine to me.
Regards
Rüdiger
Jim Jagielski wrote:
On Oct 1, 2007, at 4:07 PM, William A. Rowe, Jr. wrote:
Jim Jagielski wrote:
But, as I read it, the '*' in OPTIONS * does not really
mean a Location *... in other words, it's not a URI per se.
OPTIONS * asks for the capabilities of the server itself,
independent of
Jim Jagielski wrote:
Comments?:
Just one;
Index: modules/http/http_core.c
===
--- modules/http/http_core.c(revision 581205)
+++ modules/http/http_core.c(working copy)
@@ -234,6 +234,24 @@
return OK;
}
+static
On Oct 2, 2007, at 12:23 PM, William A. Rowe, Jr. wrote:
The more I think about this, if Location * is supported at all it
should be the first-applied, global setting of any request, not just
OPTIONS * (there really is no reason for specific exceptions.)
For that matter LocationMatch .* IS
On Oct 2, 2007, at 3:32 PM, Roy T. Fielding wrote:
On Oct 2, 2007, at 12:23 PM, William A. Rowe, Jr. wrote:
The more I think about this, if Location * is supported at all it
should be the first-applied, global setting of any request, not just
OPTIONS * (there really is no reason for specific
On Oct 2, 2007, at 12:50 PM, Jim Jagielski wrote:
The current rec does that. Since * does not map to
any storage, or, in fact to any Location, it simply creates
the Allow from the server capabilities.
Allow only applies to URIs, not *. I have a fix for that.
Roy
Roy T. Fielding wrote:
I was only talking about the OPTIONS /path case. * is a special
case of a true null request -- it should only deal with server
capabilities and ignore Location/Directory configs.
Could you clarify, though? If PROPGET or PUT is supported on some
subset of the server
On Oct 2, 2007, at 1:34 PM, William A. Rowe, Jr. wrote:
Roy T. Fielding wrote:
I was only talking about the OPTIONS /path case. * is a special
case of a true null request -- it should only deal with server
capabilities and ignore Location/Directory configs.
Could you clarify, though? If
On Tue, 2 Oct 2007 14:07:45 -0700
Roy T. Fielding [EMAIL PROTECTED] wrote:
On Oct 2, 2007, at 1:39 PM, Roy T. Fielding wrote:
Nope. * is not a resource. Since it is impossible to know the
mask of the entire resource space, HTTP does not require that
Allow be included on OPTIONS *
On Oct 2, 2007, at 1:39 PM, Roy T. Fielding wrote:
Nope. * is not a resource. Since it is impossible to know the
mask of the entire resource space, HTTP does not require that
Allow be included on OPTIONS * responses. Just committed a fix.
Hmm, I am still seeing an Allow header even after my
On Oct 2, 2007, at 4:39 PM, Roy T. Fielding wrote:
On Oct 2, 2007, at 1:34 PM, William A. Rowe, Jr. wrote:
Roy T. Fielding wrote:
I was only talking about the OPTIONS /path case. * is a special
case of a true null request -- it should only deal with server
capabilities and ignore
On Oct 2, 2007, at 5:07 PM, Roy T. Fielding wrote:
On Oct 2, 2007, at 1:39 PM, Roy T. Fielding wrote:
Nope. * is not a resource. Since it is impossible to know the
mask of the entire resource space, HTTP does not require that
Allow be included on OPTIONS * responses. Just committed a fix.
On 10/02/2007 11:21 PM, Jim Jagielski wrote:
On Oct 2, 2007, at 4:39 PM, Roy T. Fielding wrote:
On Oct 2, 2007, at 1:34 PM, William A. Rowe, Jr. wrote:
Roy T. Fielding wrote:
I was only talking about the OPTIONS /path case. * is a special
case of a true null request -- it should only
On Mon, Oct 01, 2007 at 12:05:58AM +0100, Nick Kew wrote:
RFC2616 is clear that:
1. OPTIONS * is allowed.
2. OPTIONS can be proxied.
However, it's not clear that OPTIONS * can be proxied,
given that there's no natural URL representation of it (* != /*).
The Co-Advisor suite has a
On 10/1/07, Jim Jagielski [EMAIL PROTECTED] wrote:
I know Roy's already reported the proxy error as bogus, but I think
the OPTIONS * BUGZ report is also bogus. As a test, I assumed that
both www.apache.org and apache.webthing.com are reasonably configured
servers:
www.apache.org is using a
On 10/01/2007 03:30 PM, Joshua Slive wrote:
On 10/1/07, Jim Jagielski [EMAIL PROTECTED] wrote:
I know Roy's already reported the proxy error as bogus, but I think
the OPTIONS * BUGZ report is also bogus. As a test, I assumed that
both www.apache.org and apache.webthing.com are reasonably
On Mon, 01 Oct 2007 16:43:57 +0200
Ruediger Pluem [EMAIL PROTECTED] wrote:
On 10/01/2007 03:30 PM, Joshua Slive wrote:
On 10/1/07, Jim Jagielski [EMAIL PROTECTED] wrote:
[summary of everyone]
No problem.
OK, it's actually applying the permissions of DocumentRoot.
It's also ignoring the
Nick Kew wrote:
RFC2616 tells us OPTIONS * is basically a simple HTTP ping,
which suggests it could be at a 'lower' level than authconfig
and always be allowed. If there is a reason to deny it,
that could be by means of something analagous to TraceEnable.
Insufficient.
If we configure
On Mon, 1 Oct 2007 16:14:14 +0100
Nick Kew [EMAIL PROTECTED] wrote:
RFC2616 tells us OPTIONS * is basically a simple HTTP ping,
which suggests it could be at a 'lower' level than authconfig
and always be allowed. If there is a reason to deny it,
that could be by means of something analagous
On Oct 1, 2007, at 12:02 PM, Nick Kew wrote:
On Mon, 1 Oct 2007 16:14:14 +0100
Nick Kew [EMAIL PROTECTED] wrote:
RFC2616 tells us OPTIONS * is basically a simple HTTP ping,
which suggests it could be at a 'lower' level than authconfig
and always be allowed. If there is a reason to deny it,
On Oct 1, 2007, at 11:14 AM, Nick Kew wrote:
On Mon, 01 Oct 2007 16:43:57 +0200
Ruediger Pluem [EMAIL PROTECTED] wrote:
On 10/01/2007 03:30 PM, Joshua Slive wrote:
On 10/1/07, Jim Jagielski [EMAIL PROTECTED] wrote:
[summary of everyone]
No problem.
OK, it's actually applying the
Jim Jagielski wrote:
TRACE also does not/should not trace to the filesystem.
So, I think what we should do is use the existing
architecture and have a quick_handler that checks for
the OPTIONS * case and, if so, return DONE.
You can't ignore the vhost, and preferably would handle the
On Oct 1, 2007, at 2:17 PM, William A. Rowe, Jr. wrote:
Jim Jagielski wrote:
TRACE also does not/should not trace to the filesystem.
So, I think what we should do is use the existing
architecture and have a quick_handler that checks for
the OPTIONS * case and, if so, return DONE.
You can't
On Oct 1, 2007, at 2:33 PM, Jim Jagielski wrote:
On Oct 1, 2007, at 2:17 PM, William A. Rowe, Jr. wrote:
Jim Jagielski wrote:
TRACE also does not/should not trace to the filesystem.
So, I think what we should do is use the existing
architecture and have a quick_handler that checks for
the
Jim Jagielski wrote:
Hmmm on 2nd thought, map_to_storage is likely the more logical
place.
The answer, of course, is with the next version of apache, to finish
abstracting out the filesystem at map_to_storage; where there is no
DocumentRoot / FilePathAlias (e.g. alias) to force some other
On 10/1/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
But I'm rather against breaking this in 2.2 to solve (what are, today)
configuration quirks. Let's get this right for 2.4 and call out the
change very clearly in (our overlong) CHANGES? I'm thinking of a new
second-priority category
Joshua Slive wrote:
On 10/1/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
But I'm rather against breaking this in 2.2 to solve (what are, today)
configuration quirks. Let's get this right for 2.4 and call out the
change very clearly in (our overlong) CHANGES? I'm thinking of a new
On Mon, Oct 01, 2007 at 12:05:41PM -0700, Roy T. Fielding wrote:
On Oct 1, 2007, at 11:02 AM, Jim Jagielski wrote:
TRACE also does not/should not trace to the filesystem.
So, I think what we should do is use the existing
architecture and have a quick_handler that checks for
the OPTIONS * case
On 10/1/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
Joshua Slive wrote:
Should be in this, rather sparse file:
http://httpd.apache.org/docs/trunk/new_features_2_4.html
But it's not a feature-per say. It's a bugfix, so the name new_features
doesn't tell admins they have to adopt a
Jim Jagielski wrote:
Great! That's exactly what I needed to know.
So it seems to me that a map_to_storage to check for
the special case of '*' whereas present action for
all other URIs is the best course of action.
Provided it's vetted against the vhost (it is) and against location *
then
Joshua Slive wrote:
On 10/1/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote:
Joshua Slive wrote:
Should be in this, rather sparse file:
http://httpd.apache.org/docs/trunk/new_features_2_4.html
But it's not a feature-per say. It's a bugfix, so the name new_features
doesn't tell admins
On Mon, Oct 01, 2007 at 03:22:34PM -0400, Jim Jagielski wrote:
On Mon, Oct 01, 2007 at 12:05:41PM -0700, Roy T. Fielding wrote:
On Oct 1, 2007, at 11:02 AM, Jim Jagielski wrote:
TRACE also does not/should not trace to the filesystem.
So, I think what we should do is use the existing
On Mon, Oct 01, 2007 at 02:30:30PM -0500, William A. Rowe, Jr. wrote:
Jim Jagielski wrote:
Great! That's exactly what I needed to know.
So it seems to me that a map_to_storage to check for
the special case of '*' whereas present action for
all other URIs is the best course of action.
Jim Jagielski wrote:
But, as I read it, the '*' in OPTIONS * does not really
mean a Location *... in other words, it's not a URI per se.
OPTIONS * asks for the capabilities of the server itself,
independent of URI... At least, that's how I read it.
There is no 'real' Location *
There's a
On sön, 2007-09-30 at 16:54 -0700, Roy T. Fielding wrote:
On Sep 30, 2007, at 4:05 PM, Nick Kew wrote:
RFC2616 is clear that:
1. OPTIONS * is allowed.
2. OPTIONS can be proxied.
However, it's not clear that OPTIONS * can be proxied,
given that there's no natural URL
RFC2616 is clear that:
1. OPTIONS * is allowed.
2. OPTIONS can be proxied.
However, it's not clear that OPTIONS * can be proxied,
given that there's no natural URL representation of it (* != /*).
The Co-Advisor suite has a test case to proxy OPTIONS * using:
OPTIONS * HTTP/1.1\r\n
Host:
On Sep 30, 2007, at 4:05 PM, Nick Kew wrote:
RFC2616 is clear that:
1. OPTIONS * is allowed.
2. OPTIONS can be proxied.
However, it's not clear that OPTIONS * can be proxied,
given that there's no natural URL representation of it (* != /*).
An absolute http request-URI with no path.
43 matches
Mail list logo
