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 <http://msdn.microsoft.com/library/en-us/http/http/httpreceivehttprequest.asp>HttpReceiveHttpRequest << collect all the headers targeted to 'this' server <http://msdn.microsoft.com/library/en-us/http/http/httpreceiverequestentitybody.asp>HttpReceiveRequestEntityBody << collect the body for this request <http://msdn.microsoft.com/library/en-us/http/http/httpsendhttpresponse.asp>HttpSendHttpResponse << respond with all the headers as an array <http://msdn.microsoft.com/library/en-us/http/http/httpsendresponseentitybody.asp>HttpSendResponseEntityBody << 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. Bill
