httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject the three filter types (was: cvs commit: httpd-2.0/server core.c)
Date Tue, 05 Mar 2002 01:53:44 GMT
On Sun, Mar 03, 2002 at 10:34:55PM -0000, 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).


Greg Stein,

View raw message