> Also, I'd like to suggest if kHTTPd added some way how to explicitely say
> which files should be served by kHTTPd and which should be taken care of in
> userspace.
In my opinion, kHTTPd should start with an empty URL->file cache, and
userland should be responsible for populating the cache.
For cache misses, it should drop the connection into a socket which will
go through the usual accept() process, and appear as if it were a regular
socket.
Then let the userland use ioctl()s to map URLs->files, and to supply the
rest of the response headers to go along with the response.
This design would work with almost no changes to apache. A module could
be added to apache which deals with the ioctl() to map URLs to files. The
only difficult thing is telling the kernel that a particular listening
socket should have kHTTPd attached to it... for this you'd have to tweak
the core, because currently modules can't get the fd for the listening
sockets.
But the changes to apache are minimal -- and this configuration works not
only for static page style webserving, but also works for proxy caches...
and a lot of other situations.
And it also lets all the apache configuration controls come into play...
because the cache module could be configured to not indicate caching on
any resource which has access protection, for example.
And it puts the mapping of extensions to content-types, and such, into the
control of user-space.
A pipe or other method is needed to get cache hit reports out of kHTTPd.
Dean
p.s. in the way of optimizations -- all common HTTP clients send their
headers in the first packet. kHTTPd would be "good enough" if it bailed
to userland every time it determined that the request crossed a packet
boundary.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/