You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by rb...@apache.org on 2002/03/03 23:34:55 UTC
cvs commit: httpd-2.0/server core.c
rbb 02/03/03 14:34:55
Modified: modules/http http_core.c
server core.c
Log:
Classify some of the input filters as the correct types. Previous to
this patch, the type wasn't too important, because all filters were
put on the same list. After this patch, the filter type is very important,
because there are three different types of filters, and they are all treated
differently, namely:
CONNECTION: Filters of this type are valid for the lifetime of this
connection.
PROTOCOL: Filters of this type are valid for the lifetime of this
request from the point of view of the client, this means
that the request is valid from the time that the request
is sent until the time that the response is received.
CONTENT: Filters of this type are valid for the time that this
content is used to satisfy a request. For simple requests,
this is identical to PROTOCOL, but internal redirects
and sub-requests can change the content without ending
the request.
It is important to realize that the three major types above are actually
broken down into smaller groups in the code, to ensure that the ordering
of filters is always correct.
Revision Changes Path
1.294 +1 -1 httpd-2.0/modules/http/http_core.c
Index: http_core.c
===================================================================
RCS file: /home/cvs/httpd-2.0/modules/http/http_core.c,v
retrieving revision 1.293
retrieving revision 1.294
diff -u -r1.293 -r1.294
--- http_core.c 29 Jan 2002 19:02:03 -0000 1.293
+++ http_core.c 3 Mar 2002 22:34:55 -0000 1.294
@@ -324,7 +324,7 @@
ap_hook_insert_filter(ap_http_insert_filter, NULL, NULL, APR_HOOK_REALLY_LAST);
ap_http_input_filter_handle =
ap_register_input_filter("HTTP_IN", ap_http_filter,
- AP_FTYPE_CONNECTION);
+ AP_FTYPE_HTTP_HEADER);
ap_http_header_filter_handle =
ap_register_output_filter("HTTP_HEADER", ap_http_header_filter,
AP_FTYPE_HTTP_HEADER);
1.154 +1 -1 httpd-2.0/server/core.c
Index: core.c
===================================================================
RCS file: /home/cvs/httpd-2.0/server/core.c,v
retrieving revision 1.153
retrieving revision 1.154
diff -u -r1.153 -r1.154
--- core.c 26 Feb 2002 04:04:54 -0000 1.153
+++ core.c 3 Mar 2002 22:34:55 -0000 1.154
@@ -3885,7 +3885,7 @@
AP_FTYPE_NETWORK);
ap_net_time_filter_handle =
ap_register_input_filter("NET_TIME", net_time_filter,
- AP_FTYPE_CONTENT);
+ AP_FTYPE_HTTP_HEADER);
ap_content_length_filter_handle =
ap_register_output_filter("CONTENT_LENGTH", ap_content_length_filter,
AP_FTYPE_HTTP_HEADER);
Re: the three filter types
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Mar 04, 2002 at 11:13:29PM -0600, William A. Rowe, Jr. wrote:
> At 07:53 PM 3/4/2002, you wrote:
>
> >Just wanted to state that I believe Ryan has the correct distinction here --
> >that we have three types of filters. However, the third type is a misnomer,
> >and we can derive the proper name from the HTTP model: "resource"
>
> Resource, body, content, whichever.
In HTTP, it is a resource you're make a request against. The body and
content are aspects of the protocol (the "message", in particular).
> The trick is that any 'resource' can be
> aggregated, while the connection filters are pretty fixed [or mutate in stable
> ways, such as connection:upgrade semantics], protocol filters are pretty
> fixed [they are designed by the top resource],
The protocol is *not* defined by the resource. It is defined by the
underlying connection. My client is connecting to the server with a
particular protocol. The resource that I talk to has *nothing* to do with
that.
> but we can munge together
> a bunch of 'resource' streams into one 'request' [as once defined in 1.3 :-]
Yup. For instance, a PROPFIND returning data from many resources (mod_dav
defines a "walk" API over resources to do this).
SSI allows you to incorporate multiple resources, but this is tricky ground.
There are public resources, and then there are resources that could be
entirely private to the server (such as a CGI invoked only thru SSI, but it
doesn't have a URL associated with it). The distinction could be important.
> >In HTTP, you talk to a resource on the server. With our redirect stuff, all
> >we're doing is pointing to a different resource. The connection and protocol
> >remain the same.
>
> Bingo, for the most part. Absolutely on when it comes to merging several
> resources [sub-requests]. Only thing is that which resource will have some
> thing to do with the protocol (want the .gz flavor? here it is...)
No, the protocol adjusts itself based on characteristics of the resource and
what the client requested. For example, with .gz, the protocol sees the
"Accept-Encoding" and turns on the compression. But the protocl might also
look at the resource's type and say, "hmm. it's a jpeg. that isn't going to
compress."
Point is: the resource is strictly hidden from protocol concerns.
> >In Apache 2.1, I'd like to move towards the resource model, and also create
> >a resource mapping tree. Rather than this whole "location / directory" walk
> >crap, we navigate down a tree. Each node identifies a different provider of
> >resources. The root node ("/") refers to the filesystem provider, keyed in
> >at DocumentRoot. The Alias directive creates new nodes in the location tree,
> >also referring to the filesystem provider, but they point to a different
> >space in the filesystem. etc etc.
>
> You sort of describe what happened with map_to_storage ... directory only
> applies to ... surprise ... files :)
>
> I don't know if we can rip away Location altogether. While it would be nice,
Holy crap. I'm not talking about taking out Location. That is the whole key
to the mechanism!
You lay out your URL space (e.g. Location directives) into a tree in memory.
At each node, you hang configuration elements, a hash table pointing to
child nodes, and a resource provider for that node and its children (of
course, unless overridden by a provider statement below that point).
> the location concept gives us some high-level abstractions, such as auth
> contexts, etc, that are still relevant/useful. But I would like to see us
> continue to 'discourage' their use ... in so far as users 'presumed' the two
> work the same. URI space != file mounts :)
I have never agreed with the concept of discouraging the Location directive.
The Location directives, and the implicit tree ("namespace") it defines are
how a user sees the site.
The Directory directive is looking at your server from the wrong direction.
Essentially, you lay out your URL space using Location and other directives
which define locations (Alias, for example; it defines a location which maps
to a directory). The Directory is then used to establish details about the
underlying filesystem, but it is *totally* independent of the Location tree.
/
subtree1/
subsub/
subtree2/
subthree/
The location tree might look like something above, and it has "providers"
associated with different points on that tree. Usually, it will be the
default filesystem provider. The filesystem provider has its own tree of
configuration data, as applied to the content in the filesystem.
/home/www/docroot/
group1/
subsub/
subtree2/
group3/
The configuration associated with the Directory directive is stored in this
tree, not in the Location tree.
When the system walks down the location tree to the target resource, it asks
the provider for additional config (beyond what may be hooked into the
location tree). That is where the filesystem provider can return the config
associated with elements in its tree (based on whatever the Location node
happened to map to in its tre).
> >Much of this resource model has already been fleshed out in mod_dav's
> >dav_resource structure.
>
> I need to study this, but I agree that replacing the filesystem altogether with
> a dav-like provider model is the only way to move forward.
>
> But not for release 2.0 :) Let's get planning for 2.1 - ROADMAP is calling.
Have no fear. The above has only been Blue Sky. Greg's Desired Resource
Model. :-)
Please return to your regularly scheduled program...
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: the three filter types (was: cvs commit: httpd-2.0/server
core.c)
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 07:53 PM 3/4/2002, you wrote:
>Just wanted to state that I believe Ryan has the correct distinction here --
>that we have three types of filters. However, the third type is a misnomer,
>and we can derive the proper name from the HTTP model: "resource"
Resource, body, content, whichever. The trick is that any 'resource' can be
aggregated, while the connection filters are pretty fixed [or mutate in stable
ways, such as connection:upgrade semantics], protocol filters are pretty
fixed [they are designed by the top resource], but we can munge together
a bunch of 'resource' streams into one 'request' [as once defined in 1.3 :-]
>In HTTP, you talk to a resource on the server. With our redirect stuff, all
>we're doing is pointing to a different resource. The connection and protocol
>remain the same.
Bingo, for the most part. Absolutely on when it comes to merging several
resources [sub-requests]. Only thing is that which resource will have some
thing to do with the protocol (want the .gz flavor? here it is...)
>In Apache 2.1, I'd like to move towards the resource model, and also create
>a resource mapping tree. Rather than this whole "location / directory" walk
>crap, we navigate down a tree. Each node identifies a different provider of
>resources. The root node ("/") refers to the filesystem provider, keyed in
>at DocumentRoot. The Alias directive creates new nodes in the location tree,
>also referring to the filesystem provider, but they point to a different
>space in the filesystem. etc etc.
You sort of describe what happened with map_to_storage ... directory only
applies to ... surprise ... files :)
I don't know if we can rip away Location altogether. While it would be nice,
the location concept gives us some high-level abstractions, such as auth
contexts, etc, that are still relevant/useful. But I would like to see us
continue to 'discourage' their use ... in so far as users 'presumed' the two
work the same. URI space != file mounts :)
>Much of this resource model has already been fleshed out in mod_dav's
>dav_resource structure.
I need to study this, but I agree that replacing the filesystem altogether with
a dav-like provider model is the only way to move forward.
But not for release 2.0 :) Let's get planning for 2.1 - ROADMAP is calling.
Good thoughts Greg;
Bill
Re: the three filter types (was: cvs commit: httpd-2.0/server
core.c)
Posted by Jim Jagielski <ji...@jaguNET.com>.
At 5:53 PM -0800 3/4/02, Greg Stein wrote:
> > CONTENT: Filters of this type are valid for the time that this
>> content is used to satisfy a request. For simple requests,
>> this is identical to PROTOCOL, but internal redirects
>> and sub-requests can change the content without ending
>> the request.
>
>Just wanted to state that I believe Ryan has the correct distinction here --
>that we have three types of filters. However, the third type is a misnomer,
>and we can derive the proper name from the HTTP model: "resource"
>
Cool (on the above as well as the ideas for 2.1). I agree that RESOURCE is
more clear.
--
===========================================================================
Jim Jagielski [|] jim@jaguNET.com [|] http://www.jaguNET.com/
"A society that will trade a little liberty for a little order
will lose both and deserve neither" - T.Jefferson
Re: the three filter types (was: cvs commit: httpd-2.0/server core.c)
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Mar 04, 2002 at 08:35:35PM -0800, Ryan Bloom wrote:
> > On Sun, Mar 03, 2002 at 10:34:55PM -0000, rbb@apache.org wrote:
>...
> > Just wanted to state that I believe Ryan has the correct distinction here --
> > that we have three types of filters. However, the third type is a misnomer,
> > and we can derive the proper name from the HTTP model: "resource"
>
> YES, resource is markedly better than CONTENT. I have been using
> resource all day when explaining this to people at work. Always scary
> when Greg and I agree. :-)
Oh, for christssakes... put up some kind of argument...
;-)
--
Greg Stein, http://www.lyra.org/
RE: the three filter types (was: cvs commit: httpd-2.0/server core.c)
Posted by Ryan Bloom <rb...@covalent.net>.
> On Sun, Mar 03, 2002 at 10:34:55PM -0000, rbb@apache.org wrote:
> > rbb 02/03/03 14:34:55
> >
> > Modified: modules/http http_core.c
> > server core.c
> > Log:
> > Classify some of the input filters as the correct types. Previous
to
> > this patch, the type wasn't too important, because all filters
were
> > put on the same list. After this patch, the filter type is very
> important,
> > because there are three different types of filters, and they are
all
> treated
> > differently, namely:
> >
> > CONNECTION: Filters of this type are valid for the lifetime
of this
> > connection.
> > PROTOCOL: Filters of this type are valid for the lifetime of this
> > request from the point of view of the client, this means
> > that the request is valid from the time that the request
> > is sent until the time that the response is received.
> > CONTENT: Filters of this type are valid for the time that this
> > content is used to satisfy a request. For simple
requests,
> > this is identical to PROTOCOL, but internal redirects
> > and sub-requests can change the content without ending
> > the request.
>
> Just wanted to state that I believe Ryan has the correct distinction
here
> --
> that we have three types of filters. However, the third type is a
> misnomer,
> and we can derive the proper name from the HTTP model: "resource"
YES, resource is markedly better than CONTENT. I have been using
resource all day when explaining this to people at work. Always scary
when Greg and I agree. :-)
Ryan
the three filter types (was: cvs commit: httpd-2.0/server core.c)
Posted by Greg Stein <gs...@lyra.org>.
On Sun, Mar 03, 2002 at 10:34:55PM -0000, rbb@apache.org wrote:
> rbb 02/03/03 14:34:55
>
> Modified: modules/http http_core.c
> server core.c
> Log:
> Classify some of the input filters as the correct types. Previous to
> this patch, the type wasn't too important, because all filters were
> put on the same list. After this patch, the filter type is very important,
> because there are three different types of filters, and they are all treated
> differently, namely:
>
> CONNECTION: Filters of this type are valid for the lifetime of this
> connection.
> PROTOCOL: Filters of this type are valid for the lifetime of this
> request from the point of view of the client, this means
> that the request is valid from the time that the request
> is sent until the time that the response is received.
> CONTENT: Filters of this type are valid for the time that this
> content is used to satisfy a request. For simple requests,
> this is identical to PROTOCOL, but internal redirects
> and sub-requests can change the content without ending
> the request.
Just wanted to state that I believe Ryan has the correct distinction here --
that we have three types of filters. However, the third type is a misnomer,
and we can derive the proper name from the HTTP model: "resource"
In HTTP, you talk to a resource on the server. With our redirect stuff, all
we're doing is pointing to a different resource. The connection and protocol
remain the same.
IMO, Apache should lose the concept of a "request_rec" except for way down
in the MPM levels. Only the MPM deals with requests. Instead, we move to a
model where "resources" are first-class objects and the server talks to them
in interesting ways. We map incoming URLs to resource objects, and let it
fly. The default resource would represent a file in the filesystem, but it
could also be a CGI script, a "file" in a Subversion repository, or the
source for a PHP script grabbed via a proxy-like socket connection.
In Apache 2.1, I'd like to move towards the resource model, and also create
a resource mapping tree. Rather than this whole "location / directory" walk
crap, we navigate down a tree. Each node identifies a different provider of
resources. The root node ("/") refers to the filesystem provider, keyed in
at DocumentRoot. The Alias directive creates new nodes in the location tree,
also referring to the filesystem provider, but they point to a different
space in the filesystem. etc etc.
Much of this resource model has already been fleshed out in mod_dav's
dav_resource structure. That resource model is how mod_dav can perform its
operations against arbitrary backend storage mechanisms. It seems perfectly
valid to promote to a more integral concept of Apache itself. That would
allow things like mod_autoindex to ask a resource for a list of "child"
resources, and to build a nicely formatted page to navigate to them (today,
mod_autoindex is hard-wired to the filesystem, which means we cannot apply
its mechanisms to collections of resources in a Subversion repository).
Cheers,
-g
--
Greg Stein, http://www.lyra.org/