← Back to branch summary

~ubuntu-branches/ubuntu/feisty/apache2/feisty

« back to all changes in this revision

Viewing changes to ROADMAP

  • Committer: Bazaar Package Importer
  • Author(s): Andreas Barth
  • Date: 2006-12-09 21:05:45 UTC
  • mfrom: (0.6.1 upstream)
  • Revision ID: james.westby@ubuntu.com-20061209210545-h70s0xaqc2v8vqr2
Tags: 2.2.3-3.2
http://bugs.debian.org/396265
* Non-maintainer upload.
* 043_ajp_connection_reuse: Patch from upstream Bugzilla, fixing a critical
  issue with regard to connection reuse in mod_proxy_ajp.
  Closes: #396265

Show diffs side-by-side

added added

removed removed

Lines of Context:
ROADMAP
 
1
APACHE 2.x ROADMAP
 
2
==================
 
3
Last modified at [$Date: 2005-03-13 23:24:22 -0600 (Sun, 13 Mar 2005) $]
 
4
 
 
5
 
 
6
WORKS IN PROGRESS
 
7
-----------------
 
8
 
 
9
    * Source code should follow style guidelines.
 
10
      OK, we all agree pretty code is good.  Probably best to clean this
 
11
      up by hand immediately upon branching a 2.1 tree.
 
12
      Status: Justin volunteers to hand-edit the entire source tree ;)
 
13
 
 
14
      Justin says:
 
15
        Recall when the release plan for 2.0 was written:
 
16
            Absolute Enforcement of an "Apache Style" for code.
 
17
        Watch this slip into 3.0.
 
18
 
 
19
      David says:
 
20
        The style guide needs to be reviewed before this can be done.
 
21
        http://httpd.apache.org/dev/styleguide.html
 
22
        The current file is dated April 20th 1998!
 
23
 
 
24
        OtherBill offers:
 
25
          It's survived since '98 because it's welldone :-)  Suggest we
 
26
          simply follow whatever is documented in styleguide.html as we
 
27
          branch the next tree.  Really sort of straightforward, if you
 
28
          dislike a bit within that doc, bring it up on the dev@httpd
 
29
          list prior to the next branch.
 
30
 
 
31
      So Bill sums up ... let's get the code cleaned up in CVS head.
 
32
      Remember, it just takes cvs diff -b (that is, --ignore-space-change)
 
33
      to see the code changes and ignore that cruft.  Get editing Justin :)
 
34
 
 
35
    * Replace stat [deferred open] with open/fstat in directory_walk.
 
36
      Justin, Ian, OtherBill all interested in this.  Implies setting up
 
37
      the apr_file_t member in request_rec, and having all modules use
 
38
      that file, and allow the cleanup to close it [if it isn't a shared,
 
39
      cached file handle.]
 
40
 
 
41
    * The Async Apache Server implemented in terms of APR.
 
42
      [Bill Stoddard's pet project.]
 
43
      Message-ID: <008301c17d42$9b446970$01000100@sashimi> (dev@apr)
 
44
 
 
45
        OtherBill notes that this can proceed in two parts...
 
46
 
 
47
           Async accept, setup, and tear-down of the request 
 
48
           e.g. dealing with the incoming request headers, prior to
 
49
           dispatching the request to a thread for processing.
 
50
           This doesn't need to wait for a 2.x/3.0 bump.
 
51
 
 
52
           Async delegation of the entire request processing chain
 
53
           Too many handlers use stack storage and presume it is 
 
54
           available for the life of the request, so a complete 
 
55
           async implementation would need to happen 3.0 release.
 
56
 
 
57
        Brian notes that async writes will provide a bigger
 
58
        scalability win than async reads for most servers.
 
59
        We may want to try a hybrid sync-read/async-write MPM
 
60
        as a next step.  This should be relatively easy to
 
61
        build: start with the current worker or leader/followers
 
62
        model, but hand off each response brigade to a "completion
 
63
        thread" that multiplexes writes on many connections, so
 
64
        that the worker thread doesn't have to wait around for
 
65
        the sendfile to complete.
 
66
 
 
67
 
 
68
MAKING APACHE REPOSITORY-AGNOSTIC
 
69
(or: remove knowledge of the filesystem)
 
70
 
 
71
[ 2002/10/01: discussion in progress on items below; this isn't
 
72
  planned yet ]
 
73
 
 
74
    * dav_resource concept for an HTTP resource ("ap_resource")
 
75
 
 
76
    * r->filename, r->canonical_filename, r->finfo need to
 
77
      disappear. All users need to use new APIs on the ap_resource
 
78
      object.
 
79
      
 
80
      (backwards compat: today, when this occurs with mod_dav and a
 
81
       custom backend, the above items refer to the topmost directory
 
82
       mapped by a location; e.g. docroot)
 
83
 
 
84
      Need to preserve a 'filename'-like string for mime-by-name
 
85
      sorts of operations.  But this only needs to be the name itself
 
86
      and not a full path.
 
87
 
 
88
      Justin: Can we leverage the path info, or do we not trust the
 
89
              user?
 
90
 
 
91
      gstein: well, it isn't the "path info", but the actual URI of
 
92
              the resource. And of course we trust the user... that is
 
93
              the resource they requested.
 
94
              
 
95
              dav_resource->uri is the field you want. path_info might
 
96
              still exist, but that portion might be related to the
 
97
              CGI concept of "path translated" or some other further
 
98
              resolution.
 
99
              
 
100
              To continue, I would suggest that "path translated" and
 
101
              having *any* path info is Badness. It means that you did
 
102
              not fully resolve a resource for the given URI. The
 
103
              "abs_path" in a URI identifies a resource, and that
 
104
              should get fully resolved. None of this "resolve to
 
105
              <here> and then we have a magical second resolution
 
106
              (inside the CGI script)" or somesuch.
 
107
   
 
108
      Justin: Well, let's consider mod_mbox for a second.  It is sort of
 
109
              a virtual filesystem in its own right - as it introduces
 
110
              it's own notion of a URI space, but it is intrinsically
 
111
              tied to the filesystem to do the lookups.  But, for the
 
112
              portion that isn't resolved on the file system, it has
 
113
              its own addressing scheme.  Do we need the ability to
 
114
              layer resolution?
 
115
 
 
116
    * The translate_name hook goes away
 
117
 
 
118
      Wrowe altogether disagrees.  translate_name today even operates
 
119
      on URIs ... this mechansim needs to be preserved.
 
120
    
 
121
    * The doc for map_to_storage is totally opaque to me. It has
 
122
      something to do with filesystems, but it also talks about
 
123
      security and per_dir_config and other stuff. I presume something
 
124
      needs to happen there -- at least better doc.
 
125
 
 
126
      Wrowe agrees and will write it up.
 
127
 
 
128
    * The directory_walk concept disappears. All configuration is
 
129
      tagged to Locations. The "mod_filesystem" module might have some
 
130
      internal concept of the same config appearing in multiple
 
131
      places, but that is handled internally rather than by Apache
 
132
      core.
 
133
 
 
134
      Wrowe suggests this is wrong, instead it's private to filesystem
 
135
      requests, and is already invoked from map_to_storage, not the core
 
136
      handler.  <Directory > and <Files > blocks are preserved as-is,
 
137
      but <Directory > sections become specific to the filesystem handler
 
138
      alone.  Because alternate filesystem schemes could be loaded, this
 
139
      should be exposed, from the core, for other file-based stores to 
 
140
      share. Consider an archive store where the layers become 
 
141
      <Directory path> -> <Archive store> -> <File name>
 
142
   
 
143
      Justin: How do we map Directory entries to Locations?
 
144
 
 
145
    * The "Location tree" is an in-memory representation of the URL
 
146
      namespace. Nodes of the tree have configuration specific to that
 
147
      location in the namespace.
 
148
      
 
149
      Something like:
 
150
      
 
151
      typedef struct {
 
152
          const char *name;  /* name of this node relative to parent */
 
153
 
 
154
          struct ap_conf_vector_t *locn_config;
 
155
 
 
156
          apr_hash_t *children; /* NULL if no child configs */
 
157
      } ap_locn_node;
 
158
 
 
159
      The following config:
 
160
      
 
161
      <Location /server-status>
 
162
          SetHandler server-status
 
163
          Order deny,allow
 
164
          Deny from all
 
165
          Allow from 127.0.0.1
 
166
      </Location>
 
167
      
 
168
      Creates a node with name=="server_status", and the node is a
 
169
      child of the "/" node. (hmm. node->name is redundant with the
 
170
      hash key; maybe drop node->name)
 
171
      
 
172
      In the config vector, mod_access has stored its Order, Deny, and
 
173
      Allow configs. mod_core has stored the SetHandler.
 
174
      
 
175
      During the Location walk, we merge the config vectors normally.
 
176
      
 
177
      Note that an Alias simply associates a filesystem path (in
 
178
      mod_filesystem) with that Location in the tree. Merging
 
179
      continues with child locations, but a merge is never done
 
180
      through filesystem locations. Config on a specific subdir needs
 
181
      to be mapped back into the corresponding point in the Location
 
182
      tree for proper merging.
 
183
 
 
184
    * Config is parsed into a tree, as we did for the 2.0 timeframe,
 
185
      but that tree is just a representation of the config (for
 
186
      multiple runs and for in-memory manipulation and usage). It is
 
187
      unrelated to the "Location tree".
 
188
 
 
189
    * Calls to apr_file_io functions generally need to be replaced
 
190
      with operations against the ap_resource. For example, rather
 
191
      than calling apr_dir_open/read/close(), a caller uses
 
192
      resource->repos->get_children() or somesuch.
 
193
 
 
194
      Note that things like mod_dir, mod_autoindex, and mod_negotation
 
195
      need to be converted to use these mechanisms so that their
 
196
      functions will work on logical repositories rather than just
 
197
      filesystems.
 
198
 
 
199
    * How do we handle CGI scripts?  Especially when the resource may
 
200
      not be backed by a file?  Ideally, we should be able to come up
 
201
      with some mechanism to allow CGIs to work in a
 
202
      repository-independent manner.
 
203
 
 
204
      - Writing the virtual data as a file and then executing it?
 
205
      - Can a shell be executed in a streamy manner?  (Portably?)
 
206
      - Have an 'execute_resource' hook/func that allows the
 
207
        repository to choose its manner - be it exec() or whatever.
 
208
        - Won't this approach lead to duplication of code?  Helper fns?
 
209
 
 
210
      gstein: PHP, Perl, and Python scripts are nominally executed by
 
211
              a filter inserted by mod_php/perl/python. I'd suggest
 
212
              that shell/batch scripts are similar.
 
213
 
 
214
              But to ask further: what if it is an executable
 
215
              *program* rather than just a script? Do we yank that out
 
216
              of the repository, drop it onto the filesystem, and run
 
217
              it? eeewwwww...
 
218
              
 
219
              I'll vote -0.9 for CGIs as a filter. Keep 'em handlers.
 
220
 
 
221
      Justin: So, do we give up executing CGIs from virtual repositories?
 
222
              That seems like a sad tradeoff to make.  I'd like to have
 
223
              my CGI scripts under DAV (SVN) control.
 
224
 
 
225
    * How do we handle overlaying of Location and Directory entries?
 
226
      Right now, we have a problem when /cgi-bin/ is ScriptAlias'd and
 
227
      mod_dav has control over /.  Some people believe that /cgi-bin/
 
228
      shouldn't be under DAV control, while others do believe it
 
229
      should be.  What's the right strategy?