Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Errors-To: <wrowe@rowe-clan.net>
Message-Id: <6.1.0.6.2.20040621222953.0785bec0@pop3.rowe-clan.net>
Date: Mon, 21 Jun 2004 22:40:08 -0500
To: dev@httpd.apache.org
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Subject: Re: Windows HTTP API
In-Reply-To: <cb7j8b$va5$1@sea.gmane.org>
References: <caim18$q3s$2@sea.gmane.org>
 <01bf01c45709$32a9d690$9e3fe204@RUFF01>
 <cb543v$1j4$1@sea.gmane.org>
 <6.1.0.6.2.20040621102652.05f46b48@pop3.rowe-clan.net>
 <40D7113C.1030207@wstoddard.com>
 <6.1.0.6.2.20040621120630.07729ec0@pop3.rowe-clan.net>
 <40D725EC.3090002@wstoddard.com>
 <6.1.0.6.2.20040621133726.075d7ec0@pop3.rowe-clan.net>
 <cb7j8b$va5$1@sea.gmane.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

At 04:17 PM 6/21/2004, Korn=E9l P=E1l wrote:
>[...]
>And I think filters that are processing raw data should be ignored for this
>MPM as they are not usefult in this situation and the raw data should be
>recreated from HTTP API structures to can be passed to filters and then
>reprocessed again. Other filters dealing with headers and entity body can=
 be
>used.

The header filters are also useless in this regard.  Construct the=
 request_rec
from the header and request data from the HTTP_REQUEST structure and
compose a new one, rather than reinvent the wheel.

All of the connection level filters are rendered moot by the semantics
of the win32 HTTP api.

>Note that it's possible to preprocess all the raw data that goes through
>http.sys, but it's not documented and resuts in performance lost.

Exactly.  As usual with MS products, the truly valuable interfaces are
rarely well documented (if at all) and tightly coupled to a specific=
 product,
e.g. IIS 6 in this case.

>And you don't have to take care of SSL at all, as you will see HTTPS and
>HTTP request the same way. The only difference is that server certificates
>has to be configured for SSL and client certificates can be retrieved.

Which is why I suggested you look at the netware ssl module.  It is only
sort-of working at the sockets level, the full blown winsock (which win32
never truly provided) integrated all of the SSL support.  Likewise with the
win32 HTTP API.

The netware ssl module stuffs the certificates as configured into the
socket and lets the socket layer handle all the handshaking details - this
is close enough to what needs to happen for the win32 HTTP API that
borrowing the config and bastardizing the initialization logic should give
you something close to workable.

Bill