Re: the three filter types (was: cvs commit: httpd-2.0/servercore.c)
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 [|] [EMAIL PROTECTED] [|] 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
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 13 :-] 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 21, 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 (eg 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
Re: the three filter types (was: cvs commit: httpd-2.0/server core.c)
On Mon, Mar 04, 2002 at 08:35:35PM -0800, Ryan Bloom wrote: On Sun, Mar 03, 2002 at 10:34:55PM -, [EMAIL PROTECTED] 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/
the three filter types (was: cvs commit: httpd-2.0/server core.c)
On Sun, Mar 03, 2002 at 10:34:55PM -, [EMAIL PROTECTED] 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/
RE: the three filter types (was: cvs commit: httpd-2.0/server core.c)
On Sun, Mar 03, 2002 at 10:34:55PM -, [EMAIL PROTECTED] 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
Re: the three filter types (was: cvs commit: httpd-2.0/server core.c)
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 13 :-] 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 21, 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 20 :) Let's get planning for 21 - ROADMAP is calling Good thoughts Greg; Bill
