httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: Windows HTTP API
Date Mon, 21 Jun 2004 17:23:23 GMT
At 11:47 AM 6/21/2004, Bill Stoddard wrote:
>William A. Rowe, Jr. wrote:
>>Thanks for the interesting references and citations.
>>Apache HTTP server works at a lower level, below the layer exposed
>>by this http.dll API.  To actually use this interface would require a few
>>1a) Either support the http channel with the apr_socket_foo() API (this
>>     is not a great option - because the interface is too high level and
>>     cannot be polled, etc)
>>1b) or Implement an alternative core filter schema which works at the
>>     http.dll API layer
>1c) Use the apr_iol patch posted to the mailing list long ago. Reimplimenting core_filter
is not practically feasible (unless you have -lots- of time to waste maintaining and debugging
a new core_filter).

Scratch my proposal 1a) - your solution 1c) is the obvious choice if the
user attempted to do this within apr...

But it's not practical, in this case because http.dll isn't just another low-level 
interface, but a very high-level interface of an full http provider.  And it turns 
out, core_filters are fairly trivial and the right solution.  If anything is busted 
in the implementation of core_filter logic (that led you to claim it wasn't
terribly practical), wouldn't 2.2 be the time to get this right?

If you wanted to keep it very clean, you could even replace our http header 
filters, since they are preprocessed under this http.dll API.

It seems overloading apr I/O is a long way around a trivial (logic) problem, 
didn't we already try and scuttle that very same sort of effort around our
overloaded memory allocation strategy?  Our conclusion was that the
overloaded memory providers were too slow, and I'm afraid for this case
that overloading in apr would create similar bottlenecks.


View raw message