httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: woah, "GET /" with autoindex
Date Sun, 07 Jan 2001 20:44:46 GMT

Ok, I can answer a lot of these questions for you.

> woah.  ok there's some serious problems here.

We know, and many of them are fixed, but not enabled, because they tend to
hide other problems, or the fix is designed, but not implemented.

> this is from a "GET / HTTP/1.0" which results in an autoindex (dunno why
> it's not grabbing one of the index.htmls, but i'm not worrying about that,
> the autoindex is probably far more interesting).

This is a known bug.  Ben Laurie is working on the fix.

> also, this is a perfect example of why zero-copy can be totally wrong.
> passing 100 bytes to the kernel in each writev() in 8 elements is way
> slower than passing the kernel 4096 byte buffers.  i haven't written up
> the test to prove it to you, but this is one of the exact problems i had
> to deal with on the last zero-copy library i worked with.
> this one is showstopper material.

I agree this is a showstopper for the release, I believe it is fine to
release a beta with this issue.  There are multiple attacks for solving
this problem.

#1, the sbrk's.  We need to keep a list of free buckets, and not allocate
a new bucket each time we create one.  At some point, each process will
create a maximum number of buckets, and we will stop allocating new ones.

This solves half the problem, but we are still allocating FAR too many
buckets for auto-index's.  The problem is that auto-index was written for
the old API, and we haven't tried to optimize that API yet.  The ap_r*
functions should all buffer data, so that they don't create a bucket per

We have a coalesce filter someplace, but I'm not sure that it has ever
been turned on.

In reality, I believe that mod_autoindex should be completely re-written
to be MUCH cleaner.  This would allow it to be used for HTTP and FTP, by
just changing one simple function, the thing that formats the results of
the stat into a string of HTML or raw data.  This has been designed, we
just need time to implement it.

> in general you want to buffer when modules are doing dynamic generation
> and you want to zero-copy when modules are sending bulk data.

We don't force zero-copy on anybody, but the core needs to figure out how
to buffer the data, which is just going to take somebody putting the logic
in.  It's not terribly complex, but nobody has had the time/inclination.

Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message