On 2010-03-16 02:03 -0400 (Tue), Gregory Collins wrote:
I think I agree with you completely. The question is: where do you draw the lines?
I like to draw the real line, as best as possible, at "do the minimal possible processing to the request" and let users chose a library to process the request and handle as much as possible. Let me expand on your examples, offering examples of reasonable situations in which one wants the opposite behaviour of your (also reasonable!) situations.
You probably want transfer-encodings handled for you....
Let's say on my server I store a lot of static content in gzip'd form. In this case, I certainly want to be handling the transfer-encoding myself, because I don't want to uncompress my compressed copy to send it to the server, only so that the server can compress it again as it sends it.
Another example: we treat responses differently based on whether you explicitly set a content length or not. If the connection is HTTP/1.0, and you don't set a content length, we have to set "Connection: close" in the response headers and close the socket when we're finished sending the response....
Another approach would be to have interface library buffer the response as it's being generated and, when it's complete, calculate the content length and pass it on to the web server. In the case of a web server doing a lot of relatively small requests, this would probably be considerably more efficient. But of course you still need to the ability to send out the response as it's being generated for large responses that quickly produce some data, but take a relatively long time to produce all of the data.
How much of that sort of logic goes into the interface layer?
I'm not sure what you mean by "interface layer," but I feel that, as
much as possible, that sort of logic should be in standalone libraries
that go between the "standard" web server interface and the user
application.
cjs
--
Curt Sampson