1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
|
APACHE 2.x ROADMAP:
Last modified at [$Date: 2002/10/01 15:44:35 $]
DEFERRRED FOR APACHE 2.1
* Source code should follow style guidelines.
OK, we all agree pretty code is good. Probably best to clean this
up by hand immediately upon branching a 2.1 tree.
Status: Justin volunteers to hand-edit the entire source tree ;)
Justin says:
Recall when the release plan for 2.0 was written:
Absolute Enforcement of an "Apache Style" for code.
Watch this slip into 3.0.
David says:
The style guide needs to be reviewed before this can be done.
http://httpd.apache.org/dev/styleguide.html
The current file is dated April 20th 1998!
OtherBill offers:
It's survived since '98 because it's welldone :-) Suggest we
simply follow whatever is documented in styleguide.html as we
branch the next tree. Really sort of straightforward, if you
dislike a bit within that doc, bring it up on the dev@httpd
list prior to the next branch.
WORKS IN PROGRESS (PERHAPS DEFERRED FOR 2.1 or 3.0)
* revamp the input filter syntax to provide for ordering of
filters created with the Set{Input|Output}Filter and the
Add{Input|Output}Filter directives. A 'relative to filterx'
syntax is definately preferable.
* Platforms that do not support fork (primarily Win32 and AS/400)
Architect start-up code that avoids initializing all the modules
in the parent process on platforms that do not support fork.
. Better yet - not only inform the startup of which phase it's in,
but allow the parent 'process' to initialize shared memory, etc,
and create a module-by-module stream to pass to the child, so the
parent can actually arbitrate the important stuff.
* Replace stat [deferred open] with open/fstat in directory_walk.
Justin, Ian, OtherBill all interested in this. Implies setting up
the apr_file_t member in request_rec, and having all modules use
that file, and allow the cleanup to close it [if it isn't a shared,
cached file handle.]
* The Async Apache Server implemented in terms of APR.
[Bill Stoddard's pet project.]
Message-ID: <008301c17d42$9b446970$01000100@sashimi> (dev@apr)
OtherBill notes that this can proceed in two parts...
Async accept, setup, and tear-down of the request
e.g. dealing with the incoming request headers, prior to
dispatching the request to a thread for processing.
This doesn't need to wait for a 2.x/3.0 bump.
Async delegation of the entire request processing chain
Too many handlers use stack storage and presume it is
available for the life of the request, so a complete
async implementation would need to happen 3.0 release.
* Add a string "class" that combines a char* with a length
and a reference count. This will help reduce the number
of strlen and strdup operations during request processing.
Including both the length and allocation will save us a ton
of reallocation we do today, in terms of string manipulation.
OtherBill asks if this is really an APR issue, not an HTTPD issue?
MAKING APACHE REPOSITORY-AGNOSTIC
(or: remove knowledge of the filesystem)
[ 2002/10/01: discussion in progress on items below; this isn't
planned yet ]
* dav_resource concept for an HTTP resource ("ap_resource")
* r->filename, r->canonical_filename, r->finfo need to
disappear. All users need to use new APIs on the ap_resource
object.
(backwards compat: today, when this occurs with mod_dav and a
custom backend, the above items refer to the topmost directory
mapped by a location; e.g. docroot)
Need to preserve a 'filename'-like string for mime-by-name
sorts of operations. But this only needs to be the name itself
and not a full path.
Justin: Can we leverage the path info, or do we not trust the user?
* The translate_name hook goes away
Wrowe altogether disagrees. translate_name today even operates
on URIs ... this mechansim needs to be preserved.
* The doc for map_to_storage is totally opaque to me. It has
something to do with filesystems, but it also talks about
security and per_dir_config and other stuff. I presume something
needs to happen there -- at least better doc.
Wrowe agrees and will write it up.
* The directory_walk concept disappears. All configuration is
tagged to Locations. The "mod_filesystem" module might have some
internal concept of the same config appearing in multiple
places, but that is handled internally rather than by Apache
core.
Wrowe suggests this is wrong, instead it's private to filesystem
requests, and is already invoked from map_to_storage, not the core
handler. <Directory > and <Files > blocks are preserved as-is,
but <Directory > sections become specific to the filesystem handler
alone. Because alternate filesystem schemes could be loaded, this
should be exposed, from the core, for other file-based stores to
share. Consider an archive store where the layers become
<Directory path> -> <Archive store> -> <File name>
* The "Location tree" is an in-memory representation of the URL
namespace. Nodes of the tree have configuration specific to that
location in the namespace.
Something like:
typedef struct {
const char *name; /* name of this node relative to parent */
struct ap_conf_vector_t *locn_config;
apr_hash_t *children; /* NULL if no child configs */
} ap_locn_node;
The following config:
<Location /server-status>
SetHandler server-status
Order deny,allow
Deny from all
Allow from 127.0.0.1
</Location>
Creates a node with name=="server_status", and the node is a
child of the "/" node. (hmm. node->name is redundant with the
hash key; maybe drop node->name)
In the config vector, mod_access has stored its Order, Deny, and
Allow configs. mod_core has stored the SetHandler.
During the Location walk, we merge the config vectors normally.
Note that an Alias simply associates a filesystem path (in
mod_filesystem) with that Location in the tree. Merging
continues with child locations, but a merge is never done
through filesystem locations. Config on a specific subdir needs
to be mapped back into the corresponding point in the Location
tree for proper merging.
* Config is parsed into a tree, as we did for the 2.0 timeframe,
but that tree is just a representation of the config (for
multiple runs and for in-memory manipulation and usage). It is
unrelated to the "Location tree".
* Calls to apr_file_io functions generally need to be replaced
with operations against the ap_resource. For example, rather
than calling apr_dir_open/read/close(), a caller uses
resource->repos->get_children() or somesuch.
Note that things like mod_dir, mod_autoindex, and mod_negotation
need to be converted to use these mechanisms so that their
functions will work on logical repositories rather than just
filesystems.
* How do we handle CGI scripts? Especially when the resource may
not be backed by a file? Ideally, we should be able to come up
with some mechanism to allow CGIs to work in a
repository-independent manner.
- Writing the virtual data as a file and then executing it?
- Can a shell be executed in a streamy manner? (Portably?)
- Have an 'execute_resource' hook/func that allows the
repository to choose its manner - be it exec() or whatever.
- Won't this approach lead to duplication of code? Helper fns?
|
