Messages in this thread | | | Date | Tue, 8 Jun 1999 17:03:28 -0700 (PDT) | From | Dean Gaudet <> | Subject | Re: Announce: kHTTPd 0.1.0 |
| |
On Tue, 8 Jun 1999, Jakub Jelinek wrote:
> 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/
| |