You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Nick Kew <ni...@webthing.com> on 2007/10/01 01:05:58 UTC
Proxying OPTIONS *
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?
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
Re: Proxying OPTIONS *
Posted by Jim Jagielski <ji...@devsys.jaguNET.com>.
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 [|] jim@jaguNET.com [|] http://www.jaguNET.com/
"If you can dodge a wrench, you can dodge a ball."
Re: Proxying OPTIONS *
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
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 *
Posted by Jim Jagielski <ji...@jaguNET.com>.
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 exceptions.)
>>
>> For that matter <LocationMatch ".*" > 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: proxy health checks [was: Proxying OPTIONS *]
Posted by Nick Kew <ni...@webthing.com>.
On Wed, 03 Oct 2007 15:04:52 +0200
Rainer Jung <ra...@kippdata.de> 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 independently from request handling.
Indeed. That could apply to other backends (such as mod_dbd) too.
> For this one would need some scheduling service (independent threads,
> API extension for callbacks). A simple start could be something like
> the monitor() hook. Although that one depends on the type of MPM and
> the module scheduling service should not be decoupled from the timing
> of important internal procedures.
Patches welcome!
Maybe a scheduled event thread could be a standard feature for httpd-3,
to make this kind of thing straightforward.
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
Re: proxy health checks [was: Proxying OPTIONS *]
Posted by "Akins, Brian" <Br...@turner.com>.
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 origin passes 2 health checks in a row, it is marked up; when it
fails 3 in a row, it is marked down. We check each backend every x seconds
(x usually equal to 5).
The proxy module and the health checker are linked via a simple array in
shared memory. The health checker marks the index of each origin as 1 (up)
or 0 (down).
I have been contemplating writing a balancer module that implements this,
but haven't had the time.
With this method, we don't have to check every time, as we assume if the
origin is up in the health checker that it is up.
This works several million times a day for us :)
(Also, we do "true" connection pooling to the origins, but that's another
story...)
--
Brian Akins
Chief Operations Engineer
Turner Digital Media Technologies
proxy health checks [was: Proxying OPTIONS *]
Posted by Rainer Jung <ra...@kippdata.de>.
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 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...
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 independently from request handling.
For this one would need some scheduling service (independent threads,
API extension for callbacks). A simple start could be something like the
monitor() hook. Although that one depends on the type of MPM and the
module scheduling service should not be decoupled from the timing of
important internal procedures.
Regards,
Rainer
Re: Proxying OPTIONS *
Posted by Jim Jagielski <ji...@jaguNET.com>.
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 *
Posted by Ruediger Pluem <rp...@apache.org>.
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 *
Posted by Jim Jagielski <ji...@jaguNET.com>.
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 *
Posted by Jim Jagielski <ji...@jaguNET.com>.
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 *
Posted by Nick Kew <ni...@webthing.com>.
On Tue, 2 Oct 2007 14:07:45 -0700
"Roy T. Fielding" <fi...@gbiv.com> 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 *
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
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 *
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
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 *
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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 *
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
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 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 *
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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' <Location "*">
>>
>> There's a <Location "/*">, or a <LocationMatch ".*">
>>
>> But since Location is segment-delimited, <Location "*"> would
>> only affect OPTIONS *.
>>
>
> I'm not sure what you're getting at here... Are you saying
> you want:
>
> <Location *>
> blah blah
> </Location>
>
> to somehow affect what OPTIONS * returns?
That was my thought, yes.
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 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 *
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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 *
Posted by Ruediger Pluem <rp...@apache.org>.
On 10/02/2007 03:16 PM, Jim Jagielski wrote:
> Comments?:
Looks fine to me.
Regards
Rüdiger
Re: Proxying OPTIONS *
Posted by Jim Jagielski <ji...@jaguNET.com>.
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 *
Posted by Jim Jagielski <ji...@jaguNET.com>.
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' <Location "*">
>
> There's a <Location "/*">, or a <LocationMatch ".*">
>
> But since Location is segment-delimited, <Location "*"> would
> only affect OPTIONS *.
>
I'm not sure what you're getting at here... Are you saying
you want:
<Location *>
blah blah
</Location>
to somehow affect what OPTIONS * returns?
Re: Proxying OPTIONS *
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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 <Location "/*">, or a <LocationMatch ".*">
But since Location is segment-delimited, <Location "*"> would
only affect OPTIONS *.
Bill
Re: Proxying OPTIONS *
Posted by Jim Jagielski <ji...@devsys.jaguNET.com>.
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 <location *>
> 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 [|] jim@jaguNET.com [|] http://www.jaguNET.com/
"If you can dodge a wrench, you can dodge a ball."
Re: Proxying OPTIONS *
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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 ++1, sounds great!
(Note we could even shortcut everything after one <location *> mapping
and not do the followup <location *> remapping - which occurs on all other
patterns such as directory or proxy blocks!)
Bill
Re: Proxying OPTIONS *
Posted by Jim Jagielski <ji...@devsys.jaguNET.com>.
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 [|] jim@jaguNET.com [|] http://www.jaguNET.com/
"If you can dodge a wrench, you can dodge a ball."
Re: Proxying OPTIONS *
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
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 *
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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 *
Posted by Jim Jagielski <ji...@jaguNET.com>.
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 <Directory /docroot> 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 *
Posted by Jim Jagielski <ji...@jaguNET.com>.
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 <Directory /docroot> 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 *
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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 <Directory /docroot> 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 *
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Oct 1, 2007, at 11:14 AM, Nick Kew wrote:
> On Mon, 01 Oct 2007 16:43:57 +0200
> Ruediger Pluem <rp...@apache.org> wrote:
>
>> On 10/01/2007 03:30 PM, Joshua Slive wrote:
>>> On 10/1/07, Jim Jagielski <ji...@devsys.jagunet.com> wrote:
>>
>> [summary of everyone]
>> No problem.
>
> OK, it's actually applying the permissions of DocumentRoot.
> It's also ignoring the permissions on <Location />
>
> 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 *
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Joshua Slive wrote:
> On 10/1/07, William A. Rowe, Jr. <wr...@rowe-clan.net> 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 *
Posted by Joshua Slive <jo...@slive.ca>.
On 10/1/07, William A. Rowe, Jr. <wr...@rowe-clan.net> 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 *
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Joshua Slive wrote:
> On 10/1/07, William A. Rowe, Jr. <wr...@rowe-clan.net> 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 *
Posted by Joshua Slive <jo...@slive.ca>.
On 10/1/07, William A. Rowe, Jr. <wr...@rowe-clan.net> 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 *
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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. <VirtualHost > would. <Location *>
should (and I'm not stating <LocationMatch .*> or <Location />, 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 *
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Oct 1, 2007, at 12:02 PM, Nick Kew wrote:
> On Mon, 1 Oct 2007 16:14:14 +0100
> Nick Kew <ni...@webthing.com> 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)
> + <Limit OPTIONS>
> + Order Allow,Deny
> + Allow from all
> + </Limit>
> </Directory>
>
> #
>
> 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 *
Posted by Nick Kew <ni...@webthing.com>.
On Mon, 1 Oct 2007 16:14:14 +0100
Nick Kew <ni...@webthing.com> 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)
+ <Limit OPTIONS>
+ Order Allow,Deny
+ Allow from all
+ </Limit>
</Directory>
#
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 *
Posted by Nick Kew <ni...@webthing.com>.
On Mon, 01 Oct 2007 16:43:57 +0200
Ruediger Pluem <rp...@apache.org> wrote:
> On 10/01/2007 03:30 PM, Joshua Slive wrote:
> > On 10/1/07, Jim Jagielski <ji...@devsys.jagunet.com> wrote:
>
> [summary of everyone]
> No problem.
OK, it's actually applying the permissions of DocumentRoot.
It's also ignoring the permissions on <Location />
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:
<Directory />
DENY
</Directory>
DocumentRoot /usr/local/apache/htdocs
<Directory /usr/local/apache/htdocs>
# no access/authnz directives at all here
</Directory>
<Location />
ALLOW
</Location>
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 *
Posted by Ruediger Pluem <rp...@apache.org>.
On 10/01/2007 03:30 PM, Joshua Slive wrote:
> On 10/1/07, Jim Jagielski <ji...@devsys.jagunet.com> 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
> <Directory /> was not restricted. To hit the (alleged) bug, you'd need
> to test on a server using the 2.2 default:
> <Directory />
> Order deny,allow
> Deny from all
> </Directory>
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 *
Posted by Joshua Slive <jo...@slive.ca>.
On 10/1/07, Jim Jagielski <ji...@devsys.jagunet.com> 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
<Directory /> was not restricted. To hit the (alleged) bug, you'd need
to test on a server using the 2.2 default:
<Directory />
Order deny,allow
Deny from all
</Directory>
(I haven't done this testing myself, so I have nothing else to
contribute on the issue.)
Joshua.
Re: Proxying OPTIONS *
Posted by Jim Jagielski <ji...@devsys.jaguNET.com>.
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 *
Posted by Henrik Nordstrom <he...@henriknordstrom.net>.
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
Re: Proxying OPTIONS *
Posted by "Roy T. Fielding" <ro...@gmail.com>.
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