> > OTOH, I can't see why it's impossible to do it completely transparent
> > for the userspace server -- if request is recognized as not usable for the
> > in-kernel processing, HTTP server just receives it like if nothing
> > happened. And, in more "advanced" model, userspace process can do some
> > "special" shutdown/close operation on its socket, transferring further
> > control over it to the in-kernel server (but then future accept() will be
> > able to receive the same TCP connection again, and it will look like
> > different fd).
> Yes, the proposal should go to web server developers, not to linux-kernel.
> There is many problems, not only regarding HTTP1.1, but also virtual
> servers. These cannot be solved with just socket's pushing and shutdown.
> They need a more complex communication semantics among in-kernel and
> userland processes. Perhaps, especially for HTTP1.1, all
> client communication tasks must be dealt by the khttpd with further "ipcs"
> to user processes. In these case they have to agree at least in basic
> configuration options (documents directories, directory
> user authentification, mime-types, follow-links, log files, log formats,
> put and post processing, etc., etc.).
This brings up another interesting point -- HTTP Digest authentication
also requires buckets of state maintenance from what I understand. That
might be quite a bit of trouble to deal with.
--- tani hosokawa river styx internet
- 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/