httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm MacCarthaigh <c...@stdlib.net>
Subject Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Date Sat, 03 Dec 2005 20:52:38 GMT
On Sat, Dec 03, 2005 at 11:36:10AM -0800, Paul Querna wrote:
> * Async/Event MPM: Complete Async pipeline for static files.  I believe 
> we can seriously give every existing single-threaded-event-based server 
> a run for their money on every existing benchmark.  Toss in some dynamic 
> content, and a hybrid Event/Worker has serious potential.  Some of this 
> work is ongoing in the async-read dev branch, but there is plenty more 
> to do.
> 
> * A Perchild MPM/replacement:  The SoC  perchild-replacement project 
> didn't work out.  We have a basic design that is sound, but we need to 
> actually write the code.
> 
> * HTTP Removed from the core:  I would like to be able to build with 
> --disable-http. Sounds crazy, but it will hopefully shrink the core, and 
> help us improve other protocol handlers like mod_ftp and mod_smtpd.

Ideas based on prior discussions and personal desires;

  * A threaded MPM to become the default: I would like mod_cgid
    to die, and for there to be a mod_execd, with an optional ap_exec()
    provider. Every place that would have a fork()/exec() can then use
    some ap_ function which takes an environment pointer (or NULL for
    unchanged), some structure for option suexec stuff, and returns
    filehandles for out/in/err. On non-unix/non-threaded it's a noop or
    just forks and exec. On threaded, we use a mod_execd (possible with
    pre-forking) and pass file descriptors over a local socket.
  
    Weed out other thread-safety nits like the lexx/yacc generated
    stuff. 

  * Configurable buffer sizes; This work is really in apr, and some of
    it is done, but buckets need to be tackled next and then it needs to
    be hacked in-httpd. But it would be nice to be able to configure the
    buffer size used for reading files, both when we read() them and
    when we call sendfile() on them, because that's how we get to
    scalable TCP flows. Setting "txqueuelen" on an interface isn't much
    use without application support for buffering similar ammounts - but
    that's what admins are starting to need with the ultra-large
    Window-sizes neccessary to get really good flow-performance out of
    say a 10G link.

  * A small protocol module that lets an admin interface apache via 
    a unix domain socket. To give the admin an out-of-band channel to 
    query mod_status when their link is full, or when they've gracefully 
    stopped. 

  * Optional XML-ised output for things like mod_status

  * Build upon the aaa framework to do some more useful things. Two
    in particular I'd like, but they are awkward and contentious.
    First, is that we have a lot of third-party providers coming up
    with ways of storing state for authentication via http. Most
    often via cookies, but sometimes via url-encoded session ID's
    and so on. It's messy and ugly, but ignoring the reality of
    One-Time Passwords isn't good either, so it might be justifiable
    to come with a framework for a united approach. Making say
    mod_authnz_secureid only a small bit of work.

    The other thing I think is missing from the aaa framework is
    a way for an admin to mandate that aaa happen over an encrypted
    session only. Some magic directive that doesn't extend into
    per-dir/htaccess land that helps them out a little in making
    sure that https is being used.

Some of those I have concrete ideas on and plan to code away at, others
are a bit nebulous :)

-- 
Colm MacCárthaigh                        Public Key: colm+pgp@stdlib.net

Mime
View raw message