httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manoj Kasichainula <>
Subject My proposal for buckets/filtering in 3.0.
Date Mon, 14 Aug 2000 12:08:15 GMT
This is quite different than the other proposals. From the feedback I
got during the meeting, this isn't suitable for Apache 2.0 because
it's still not developed enough (it popped into my head *during* the
meeting after all) and it requires more rewriting of existing modules
than the current 2.0 filtering scheme. I agree with the sentiment that
says to get 2.0 out soon rather than adding more features, so I agree.

Also, I have a bad feeling someone else already put forward this idea.
But, I'll send it out anyway.

The main difference between this design and the others is that there
are more buckets and fewer filters.

Filters are things that talk to the network, and they are two-way. SSL
and chunking are filters. They don't change very much in this case; as
is the case now, they are just iols that can handle buckets.

Most everything else is a bucket in this case. Actually, they are
probably better described as matrushka dolls or those little nested
plastic barrels. In fact, I'll call them barrels to increase

Brigades don't exist in this scheme. They are just compound barrels.

I think that each barrel will have a URI-identifier. This is useful
for caching.

Content-manipulating filters in the other designs are barrels in this
one. Also, while they were "writers" in the other designs, they are
"readers" in this one. So instead of a push-style design where filters
are written to by other filters, this scheme has barrels reading from
other barrels.

So here's how a request would proceed:

- HTTP request comes in, munched on by various filters, and passed to
  the request handler.

- request handler picks out the URI that was requested, creates a URI
  barrel initialized to that URI, and reads the content and metadata
  out of it.

- The URI barrel, when created, figures out how the content should be
  delivered, and creates subbarrels to deal with them. I'll give three

  Case #1: A file on the disk
  Case #2: A cgi script that outputs postscript that gets interpreted
  into a PNG image file
  Case #3: a proxy request

  In case #1, the URI barrel figures out that it's accessing a file,
  creates a filehandle barrel, and then binds its own content-handling
  calls to the filehandle barrel.

  file -> uri -> HTTP handler

  In case #2, the URI barrel creates a CGI barrel that is initialized
  with a file barrel pointing to the CGI script. Then uri_barrel
  creates a postscript barrel initialized with the CGI barrel and the
  parameter "PNG". The URI barrel then binds its content-handling
  calls to the postscript barrel.

  CGI script file -> mod_cgi -> mod_postscript -> uri -> HTTP handler

  In case #3, the URI barrel figures out that this is a remote request
  and creates an HTTP client barrel. The URI barrel then binds its
  conent requst handler to the HTTP barrel. Maybe there needs to be an
  intervening proxy barrel, or maybe the URI barrel knows proxy
  semantics, or maybe the request handler needs smarts about HTTP
  proxies. I'm not in touch with HTTP/1.1 proxying enough to know.

  HTTP client -> uri -> HTTP server handler
- The request handler gets barrels back, and using the appropriate
  barrel functions, writes their headers and data through the filters
  back to the client.

When anything creates a barrel, it passes in:

- a pool to allocate memory from. The stuff read from the barrel must
  be in the scope of that pool.
- a list of capabilities that are required, and a list of preferred
  capabilities. capabilities include: "send-from-file-descriptor",
  "send from memory", "write-to-content", and so on.

  This feels like content negotation, which scares me. But, very
  little of it is actually necessary in a first pass. A single
  "memory-block" capability is all that's mandatory, really.
  Everything else is extra features and optimization.

The barrel bring created will then attempt to meet those wishes if
possible, or return an error.

This is really not mapped out well-enough, and needs code, which will
wait until Apache 3.0 development starts up. But, here are the cool
features I can imagine:

- non-blocking I/O can be a capability of a barrel. One API of the
  barrel would be to return the file descriptor (or "event") it is
  waiting for, so that it can be selected on, and a full event-based
  server should be possible. When some barrel three levels deep
  doesn't support non-blocking I/O, the request handler can decide to
  punt to a seperate thread. This way, different programming models
  for modules can be supported. 

- Writability would be another capability. If a barrel is writable,
  that URI is available to DAV.

- Set-asides and lifetime of data aren't that much of an issue anymore
  (or at least I haven't thought of a case where they are). Barrels
  are naturally kept around only as long as they are needed, since
  their scope is determined by the consumer of the barrel. Caching is
  done with a cacher barrel that uses a large-scoped pool, for example.

- This scheme allows not just chains of barrels, but trees. So half of
  a document can come from PHP and half can come from SSI. You just
  need a container barrel that knows what parts are interpreted by
  what modules. There could be an MS-Word barrel that munches on
  multiple HTTP requests for HTML + images. This scares me.

- Because of the content-negotiation features, a barrel can always
  figure out what the optimal format for sending content back should

- subrequests are really easy (thanks for the idea of URI barrels,

- Should allow "magic cache" like was discussed back at the June/July
  '98 meeting. In fact, it should be really easy.

There are plenty of unanswered questions here, such as how metadata
will work, how exactly proxies fit into this, and how things like DAV
collections fit in. But I'm sleepy.

View raw message