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 18:45:17 GMT
At 01:16 PM 6/21/2004, Bill Stoddard wrote:
>William A. Rowe, Jr. wrote:
>>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?
>I tried for a few months (a few years ago) to maintain custom core_*_filters to interface
to IBM's Windows kernel resident caching GET engine and it was -way- more trouble than it
was worth. Apache core*filters are a moving target and I spent a huge amount of time debugging
problems in both the customer filters and the apache core filters. The apr_iol patch solved
the problem for me perfectly. The apr_iols allowed me to use the Apache core filters and benefit
directly from all the testing provided by the user community. Using apr_iol reduced the size
and most importantly the complexity of the custom code I had to maintain. 

That's understandable, IIUC the IBM in-kernel code looks similar to a socket.

>I know nothing about the httpd.dll, so maybe iols would be useful, or maybe not. They
were useful for me for a similar (in concept) application. YMMV.

That's where http.dll's API is very different, it's a very high-level interface with
the construct

 << collect all the headers targeted to 'this' server
 << collect the body for this request
 << respond with all the headers as an array
 << send the body to the client.

You are handling an HTTP_REQUEST structure, not an arbitrary stream
of bytes from the client, so it's not a match.  This looks too far different
from Apache's socket model, so I'm afraid that working at the I/O layer
would be overkill.  Replacing the connection mechanism and request pooling
logic is the straight line.


View raw message