Re: Proxying OPTIONS *
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 is not idempotent or after the connection has not been used for a certain amount of time). The current is_connected check has a race condition if the keepalive timer of the backend server kills the connection just after our check and before it received our request. :) We already do similar with AJP where, right after ap_proxy_connect_backend() it does a quick check. I think we even discussed having HTTP do something similar awhile ago...
Re: Proxying OPTIONS *
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 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 space, is it advertised by OPTIONS *? >> >> 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. >> > > Wow. That I would not have understood from the RFC at all. 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 is not idempotent or after the connection has not been used for a certain amount of time). The current is_connected check has a race condition if the keepalive timer of the backend server kills the connection just after our check and before it received our request. Regards Rüdiger
Re: Proxying OPTIONS *
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. Hmm, I am still seeing an Allow header even after my change. Methinks the hook isn't even being called? Fixed. You had it return OK instead of DONE, so the default_handler was called and, yep, it added the Allow :)
Re: Proxying OPTIONS *
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 Location/Directory configs. Could you clarify, though? If PROPGET or PUT is supported on some subset of the server space, is it advertised by OPTIONS *? 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. Wow. That I would not have understood from the RFC at all.
Re: Proxying 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 change. Methinks the hook isn't even being called? Roy
Re: Proxying OPTIONS *
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 * responses. Just committed a fix. > > Hmm, I am still seeing an Allow header even after my change. > Methinks the hook isn't even being called? Bill returned DONE. You changed that to OK, reverting to the full standard code path after map_to_storage. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: Proxying OPTIONS *
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 PROPGET or PUT is supported on some subset of the server space, is it advertised by OPTIONS *? 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. Roy
Re: Proxying OPTIONS *
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 space, is it advertised by OPTIONS *? Bill
Re: Proxying OPTIONS *
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
Re: Proxying OPTIONS *
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 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 IS supported already - those would affect and inform the client with respect to their OPTIONS * requests. As Roy points out, if auth is required for the whole server we want to tell the client that. 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. 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.
Re: Proxying OPTIONS *
On Oct 2, 2007, at 12:23 PM, William A. Rowe, Jr. wrote: The more I think about this, if 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 IS supported already - those would affect and inform the client with respect to their OPTIONS * requests. As Roy points out, if auth is required for the whole server we want to tell the client that. 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. Roy
Re: Proxying OPTIONS *
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 int http_send_options(request_rec *r)
> +{
> +int rv;
> +if ((r->method_number != M_OPTIONS) || !r->uri || strcmp(r->uri,
> "*")) {
> +return DECLINED;
> +}
> +
> +ap_allow_standard_methods(r, MERGE_ALLOW, M_GET, M_OPTIONS, M_POST,
> -1);
> +rv = ap_send_http_options(r);
> +
> +if (rv == OK) {
> +rv = DONE;
> +}
> +
> +return rv;
> +}
I'm confused, in this shortcut path, where do we pick up M_TRACE if
it applies, and other DAV related methods as they apply to the whole
server?
Bill
Re: Proxying OPTIONS *
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 URI... At least, that's how I read it. >> >> There is no 'real' >> >> There's a , or a >> >> But since Location is segment-delimited, would >> only affect OPTIONS *. >> > > I'm not sure what you're getting at here... Are you saying > you want: > > > blah blah > > > to somehow affect what OPTIONS * returns? That was my thought, yes. The more I think about this, if 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 IS supported already - those would affect and inform the client with respect to their OPTIONS * requests. As Roy points out, if auth is required for the whole server we want to tell the client that. Bill
Re: Proxying OPTIONS *
On 10/02/2007 03:16 PM, Jim Jagielski wrote: > Comments?: Looks fine to me. Regards Rüdiger
Re: Proxying OPTIONS *
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)
+{
+int rv;
+if ((r->method_number != M_OPTIONS) || !r->uri || strcmp(r->uri,
"*")) {
+return DECLINED;
+}
+
+ap_allow_standard_methods(r, MERGE_ALLOW, M_GET, M_OPTIONS,
M_POST, -1);
+rv = ap_send_http_options(r);
+
+if (rv == OK) {
+rv = DONE;
+}
+
+return rv;
+}
+
+
static void register_hooks(apr_pool_t *p)
{
/**
@@ -252,6 +270,7 @@
}
ap_hook_map_to_storage
(ap_send_http_trace,NULL,NULL,APR_HOOK_MIDDLE);
+ap_hook_map_to_storage
(http_send_options,NULL,NULL,APR_HOOK_MIDDLE);
ap_hook_http_scheme(http_scheme,NULL,NULL,APR_HOOK_REALLY_LAST);
ap_hook_default_port(http_port,NULL,NULL,APR_HOOK_REALLY_LAST);
ap_hook_create_request(http_create_request, NULL, NULL,
APR_HOOK_REALLY_LAST);
Re: Proxying OPTIONS *
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 how I read it. There is no 'real' There's a , or a But since Location is segment-delimited, would only affect OPTIONS *. I'm not sure what you're getting at here... Are you saying you want: blah blah to somehow affect what OPTIONS * returns?
Re: Proxying OPTIONS *
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 representation of it (* != /*). > > An absolute http request-URI with no path. In RFC2068 yes, but not RFC2616.. Regards Henrik signature.asc Description: This is a digitally signed message part
Re: Proxying OPTIONS *
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' There's a , or a But since Location is segment-delimited, would only affect OPTIONS *. Bill
Re: Proxying OPTIONS *
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. > > Provided it's vetted against the vhost (it is) and against > then ++1, sounds great! > 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. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "If you can dodge a wrench, you can dodge a ball."
Re: Proxying OPTIONS *
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 > > >architecture and have a quick_handler that checks for > > >the OPTIONS * case and, if so, return DONE. > > > > fine. > > > > >I am not sure, to be honest, what we should do for > > >OPTIONS /foo if /foo is a protected entity... Reading > > >9.2: "communication options available on the request/response > > >chain... without implying a resource action or initiating a > > >resource retrieval" implies to me that ACL shouldn't even > > >enter into it and should never return a 403... Which > > >also implies that we should not honor any Limit for > > >Options either... > > > > No, what the client wants are the communication options. It is > > commonly used to find out what is required for a PUT before the > > request with big body is sent. We want to return 401, 403, ... > > > > 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. oops... one other thing. Should we allow Limit to restrict OPTIONS? Or should Limit not affect OPTIONS as an allowed method...? -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "If you can dodge a wrench, you can dodge a ball."
Re: Proxying OPTIONS *
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 they have to adopt a change (new feature implies there's >> a goodie I can exploit if I choose to)... > > Sorry, my little tiny contribution to this thread was less than > useful. I meant the even more sparse: > http://httpd.apache.org/docs/trunk/upgrading.html Woot :) Thanks.
Re: Proxying OPTIONS *
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 then ++1, sounds great! (Note we could even shortcut everything after one mapping and not do the followup remapping - which occurs on all other patterns such as directory or proxy blocks!) Bill
Re: Proxying OPTIONS *
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 change (new feature implies there's > a goodie I can exploit if I choose to)... Sorry, my little tiny contribution to this thread was less than useful. I meant the even more sparse: http://httpd.apache.org/docs/trunk/upgrading.html > > ...and hiding in docs isn't really the best place for major config-changing > bullet points that will break their previously working, 2.2 server in some > unexpected way. Hmmm... Hiding in an enormous, mostly-indecipherable CHANGES file is better? I think the upgrading guide is exactly where that stuff belongs. Joshua.
Re: Proxying OPTIONS *
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 and, if so, return DONE. > > fine. > > >I am not sure, to be honest, what we should do for > >OPTIONS /foo if /foo is a protected entity... Reading > >9.2: "communication options available on the request/response > >chain... without implying a resource action or initiating a > >resource retrieval" implies to me that ACL shouldn't even > >enter into it and should never return a 403... Which > >also implies that we should not honor any Limit for > >Options either... > > No, what the client wants are the communication options. It is > commonly used to find out what is required for a PUT before the > request with big body is sent. We want to return 401, 403, ... > 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 [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "If you can dodge a wrench, you can dodge a ball."
Re: Proxying OPTIONS *
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 >> second-priority category after SECURITY:, e.g. CONFIG: or MUSTNOTE: >> so administrators who migrate aren't surprised. > > 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 change (new feature implies there's a goodie I can exploit if I choose to)... ...and hiding in docs isn't really the best place for major config-changing bullet points that will break their previously working, 2.2 server in some unexpected way. Bill
Re: Proxying OPTIONS *
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 after SECURITY:, e.g. CONFIG: or MUSTNOTE: > so administrators who migrate aren't surprised. Should be in this, rather sparse file: http://httpd.apache.org/docs/trunk/new_features_2_4.html Joshua.
Re: Proxying OPTIONS *
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 provider to serve the request, or fail :) httpd 2.2 remains far too filesystem-centric. Bill
Re: Proxying OPTIONS *
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 and, if so, return DONE. fine. I am not sure, to be honest, what we should do for OPTIONS /foo if /foo is a protected entity... Reading 9.2: "communication options available on the request/response chain... without implying a resource action or initiating a resource retrieval" implies to me that ACL shouldn't even enter into it and should never return a 403... Which also implies that we should not honor any Limit for Options either... No, what the client wants are the communication options. It is commonly used to find out what is required for a PUT before the request with big body is sent. We want to return 401, 403, ... Roy
Re: Proxying OPTIONS *
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 OPTIONS * case and, if so, return DONE. You can't ignore the vhost, and preferably would handle the Location "*" as well in replacement for what offered before. OPTIONS is a standard mechanism for handling the cart-before-the- horse problems of things like POST with ssl renegotiation. If we can correctly respond that "you must Upgrade to SSL", or "rehandshake now" upon the initial OPTIONS query, their next POST won't fall into that trap. But all this is still valid at the quick_handler phase... Hmmm on 2nd thought, map_to_storage is likely the more logical place.
Re: Proxying OPTIONS *
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 ignore the vhost, and preferably would handle the Location "*" as well in replacement for what offered before. OPTIONS is a standard mechanism for handling the cart-before-the-horse problems of things like POST with ssl renegotiation. If we can correctly respond that "you must Upgrade to SSL", or "rehandshake now" upon the initial OPTIONS query, their next POST won't fall into that trap. But all this is still valid at the quick_handler phase... I am not sure, to be honest, what we should do for OPTIONS /foo if /foo is a protected entity... Reading 9.2: "communication options available on the request/response chain... without implying a resource action or initiating a resource retrieval" implies to me that ACL shouldn't even enter into it and should never return a 403... Which also implies that we should not honor any Limit for Options either... But if OPTIONS /uploads is a directory, while /uploads/ is a PUT- enabled web space, shouldn't we distinguish? w.r.t. auth, if they aren't logged in, /uploads/ doesn't include PUT. That's what I want Roy to clear up... Certainly PUT is a valid communication option, right, it's just that when they do that they get a Auth Required response? You can *do* a PUT, you just may not be *authorized* for the resource, which I think are 2 distinct things.
Re: Proxying OPTIONS *
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 Location "*" as well in replacement for what offered before. OPTIONS is a standard mechanism for handling the cart-before-the-horse problems of things like POST with ssl renegotiation. If we can correctly respond that "you must Upgrade to SSL", or "rehandshake now" upon the initial OPTIONS query, their next POST won't fall into that trap. > I am not sure, to be honest, what we should do for > OPTIONS /foo if /foo is a protected entity... Reading > 9.2: "communication options available on the request/response > chain... without implying a resource action or initiating a > resource retrieval" implies to me that ACL shouldn't even > enter into it and should never return a 403... Which > also implies that we should not honor any Limit for > Options either... But if OPTIONS /uploads is a directory, while /uploads/ is a PUT-enabled web space, shouldn't we distinguish? w.r.t. auth, if they aren't logged in, /uploads/ doesn't include PUT. Now I'd totally agree that we want a smarter API for OPTIONS to allow resources to look at the auth results to decide 'yea, PUT's in that list' or 'nope, axe PUT'. > Before I work on the fix > (http://issues.apache.org/bugzilla/attachment.cgi?id=20902 > seems just plain wrong to me), I'd like to see what > Roy thinks about the above compliance points... Agreed.
Re: Proxying OPTIONS *
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 permissions of DocumentRoot. It's also ignoring the permissions on So my report was wrong, but we still have a bug: we shouldn't be mapping OPTIONS * to the filesystem. 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. I am not sure, to be honest, what we should do for OPTIONS /foo if /foo is a protected entity... Reading 9.2: "communication options available on the request/response chain... without implying a resource action or initiating a resource retrieval" implies to me that ACL shouldn't even enter into it and should never return a 403... Which also implies that we should not honor any Limit for Options either... Before I work on the fix (http://issues.apache.org/bugzilla/ attachment.cgi?id=20902 seems just plain wrong to me), I'd like to see what Roy thinks about the above compliance points...
Re: Proxying OPTIONS *
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, that could be by means of something analagous to TraceEnable. An option that fixes this in httpd.conf would be: --- docs/conf/httpd.conf.in (revision 580782) +++ docs/conf/httpd.conf.in (working copy) @@ -113,6 +113,12 @@ Options FollowSymLinks AllowOverride None Require all denied + +# Allow OPTIONS * (simple HTTP ping) + +Order Allow,Deny +Allow from all + # Otherwise a simple function running REALLY_FIRST on the access hook could check for OPTIONS. Why not use a quick_handler for the OPTIONS * case?
Re: Proxying OPTIONS *
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 to TraceEnable. An option that fixes this in httpd.conf would be: --- docs/conf/httpd.conf.in (revision 580782) +++ docs/conf/httpd.conf.in (working copy) @@ -113,6 +113,12 @@ Options FollowSymLinks AllowOverride None Require all denied + +# Allow OPTIONS * (simple HTTP ping) + +Order Allow,Deny +Allow from all + # Otherwise a simple function running REALLY_FIRST on the access hook could check for OPTIONS. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: Proxying OPTIONS *
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 server-forced connection: upgrade/TLS we had better do so in the OPTIONS phase. So I agree that files don't apply. would. should (and I'm not stating or , but an explicit case which handles only OPTIONS). 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 after SECURITY:, e.g. CONFIG: or MUSTNOTE: so administrators who migrate aren't surprised. Bill
Re: Proxying OPTIONS *
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 permissions on So my report was wrong, but we still have a bug: we shouldn't be mapping OPTIONS * to the filesystem. You can reproduce the 403 with: DENY DocumentRoot /usr/local/apache/htdocs # no access/authnz directives at all here ALLOW 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. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: Proxying OPTIONS *
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 configured >> servers: > > www.apache.org is using a config built from the 2.0 default, where > was not restricted. To hit the (alleged) bug, you'd need > to test on a server using the 2.2 default: > > Order deny,allow > Deny from all > I have done a test on 2.2.x with the above setting: telnet 192.168.2.4 80 Trying 192.168.2.4... Connected to 192.168.2.4. Escape character is '^]'. OPTIONS * HTTP/1.1 Host: 192.168.2.4 HTTP/1.1 200 OK Date: Mon, 01 Oct 2007 14:43:11 GMT Server: Apache/2.2.7-dev (Unix) mod_ssl/2.2.7-dev OpenSSL/0.9.8d DAV/2 Allow: GET,HEAD,POST,OPTIONS,TRACE Content-Length: 0 Content-Type: text/plain No problem. Regards Rüdiger
Re: Proxying OPTIONS *
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 config built from the 2.0 default, where was not restricted. To hit the (alleged) bug, you'd need to test on a server using the 2.2 default: Order deny,allow Deny from all (I haven't done this testing myself, so I have nothing else to contribute on the issue.) Joshua.
Re: Proxying OPTIONS *
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 test case to proxy OPTIONS * using: > > OPTIONS * HTTP/1.1\r\n > Host: [remote target host]\r\n > \r\n > > Unfortunately PR#43519 is obscuring the Co-Advisor test case > (which purports to be testing our handline of Max-Forwards) > by returning 403. > > It's not at all clear to me whether that syntax should > be supported. Anyone? > 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: $ telnet apache.webthing.com 80 Trying 195.50.92.131... Connected to www.webthing.com. Escape character is '^]'. OPTIONS * HTTP/1.1 Host: apache.webthing.com HTTP/1.1 200 OK Date: Mon, 01 Oct 2007 12:58:45 GMT Server: Apache/2.2.5 (Unix) DAV/2 mod_ssl/2.2.5 OpenSSL/0.9.8a SVN/1.2.3 Allow: GET,HEAD,POST,OPTIONS,TRACE Content-Length: 0 Content-Type: text/plain; charset=UTF-8 --- $ telnet apache.webthing.com 80 Trying 195.50.92.131... Connected to www.webthing.com. Escape character is '^]'. OPTIONS * HTTP/1.0 HTTP/1.1 200 OK Date: Mon, 01 Oct 2007 13:01:32 GMT Server: Apache/2.2.5 (Unix) DAV/2 mod_ssl/2.2.5 OpenSSL/0.9.8a SVN/1.2.3 Allow: GET,HEAD,POST,OPTIONS,TRACE Content-Length: 0 Connection: close Content-Type: text/plain; charset=UTF-8 Can anything confirm that OPTIONS * is as hosed as the BUGZ report claim? I haven't had time to actually trace the internals yet...
Re: Proxying OPTIONS *
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. The Co-Advisor suite has a test case to proxy OPTIONS * using: OPTIONS * HTTP/1.1\r\n Host: [remote target host]\r\n \r\n Completely bogus. Roy
