Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 48299 invoked from network); 21 Jun 2004 21:17:26 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 21 Jun 2004 21:17:26 -0000 Received: (qmail 19932 invoked by uid 500); 21 Jun 2004 21:17:37 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 19815 invoked by uid 500); 21 Jun 2004 21:17:35 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 19739 invoked by uid 99); 21 Jun 2004 21:17:32 -0000 Received: from [80.91.224.249] (HELO main.gmane.org) (80.91.224.249) by apache.org (qpsmtpd/0.27.1) with ESMTP; Mon, 21 Jun 2004 14:17:32 -0700 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BcWA3-0005Nm-00 for ; Mon, 21 Jun 2004 23:17:03 +0200 Received: from 225.51-182-adsl-pool.axelero.hu ([81.182.51.225]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 21 Jun 2004 23:17:03 +0200 Received: from kornelpal by 225.51-182-adsl-pool.axelero.hu with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 21 Jun 2004 23:17:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: dev@httpd.apache.org From: "Korn�l P�l" Subject: Re: Windows HTTP API Date: Mon, 21 Jun 2004 23:17:06 +0200 Lines: 312 Message-ID: References: <01bf01c45709$32a9d690$9e3fe204@RUFF01> <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> X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 225.51-182-adsl-pool.axelero.hu X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Sender: news X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Replay to William A. Rowe, Jr.'s 1) - 2): I think this should be implemented as new MPM as in other cases the data prepocessed by HTTP API sould be used to construct lower level things (even raw request bytes at some level) and this would kill the goals of HTTP API. Only thing you have to do is to translate HTTP API structures to Apache HTTPD connection an request structures and in reverse order on response. HTTP API provides a lot of things including pooling, the only things that Apache HTTPD has to provide are threads for processing. 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. 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. See the attached newsgroup article for details. 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. See http://msdn.microsoft.com/library/en-us/http/http/ssl_certificates.asp and http://msdn.microsoft.com/library/en-us/http/http/httpreceiveclientcertificate.asp William A. Rowe, Jr. wrote: >So it's an interesting thought experiment to me. But because all of the >headers decoding would be double-processed in the Win32 kernel and >in Apache itself, and win32 is handling this processing at the -kernel- level >(something both IIS and Apache are guilty of bungling from time to time), >the schema doesn't strike me as a secure or fast solution. I didn't see >any sendfile() or other optimized mechanisms for response bodies, maybe >I just wasn't digging deep enough. If you use Winsock the data has to be transported from kernel mode to user mode and the response in the reverse way as well as TCP/IP is implemented in kernel mode so this method cannot be slower, but it has to be faster as the data is preprocessed and only necessary data are transported. And I think HTTP API doesn't influence the security of a web server, but of course it can have it's own security holes.:) If you use kernel mode caching on static files or cacheable dynamic content it can be really fast as you can send cached content specifying it's name. And of course you are able to send data from files or from memory buffer. See http://msdn.microsoft.com/library/en-us/http/http/http_data_chunk.asp William A. Rowe, Jr. wrote: >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. You have absolutely right. HTTP API does a lot of work this work shouldn't be dismissed. Jeff White wrote: >HTTP.SYS is for quick static responses. > >They may be cached html files sent via >the Windows kernel. Not a real new big >business web server. But may be a server >for the one man shop and may be for security >of open ports, etc. :) I have to say you are wrong. HTTP API is really fast in cached responses however it doesn't mean any overhead on dynamic responses as the work it does with the request and response should be done by the web server if it don't use HTTP API. And I think HTTP API doesn't provides any extra security. Sincerely, Kornel begin 666 Re_ IIS and HTTP API.nws M1G)O;3H@(D1A=FED(%=A;F<@6TUS9G1=(B \"YG8FPA M5$LR35-&5$Y'4#$Q+G!H>"YG8FP-"EAR968Z(%1+,DU31E1.1U P."YP:'@N M9V)L(&UI8W)O2!N;W0@2!T:&4@ M:6YF;PT*:6X@,S$Q.#4R(&)E8V%U7!T+"!T:&5N('1R86YS:71I;VYE9"!B86-K(&EN=&\-"FME&5C=71E+@T*3F]T('9E2!-;V1E+"!T:&4@(FUE M8VAA;FES;2(@8V%N('5S92!I;F5T:6YF;RYE>&4@87,@=&AE(&QO;F4@=7-E M<@T*;6]D92!P&4@+2T@86YD('=H870-"FAA M<'!E;G,@:68@=&AI2!R M;W5T92!T;R!A#0IS:6YG;&4@<')O8V5S6]U(&UA>2!A2!B;V1Y(&9R;VT@1D]237,I#0H-"D9R;VT@ M;7D@<&5R2!-;V1E+@T*#0I9;W5R('-U M9V=E2!I M=',@8F5H879I;W(@>6]U('-H;W5L9 T*861D(&$@;F5W(&YO=&EF:6-A=&EO M;B!T>7!E("AI;G!U="!A;F0@;W5T<'5T(&%S('=E;&PI(&]N;'D@9F]R(&UO M9&EF>6EN9PT*=&AE(&5N=&ET>2!B;V1Y+B(@=V%S(&-O;G-I9&5R960@870@ M;VYE('!O:6YT+"!B=70@=V4@2!I M;G1R;V1U8V5D($A315]215%?15A%0U]54DP@:6X@25-!4$D@17AT96YS:6]N M(&EN($E)4S8@=&\@:&%N9&QE('1H90T*.3DN.24@=7-A9V4@8V%S92!O9B!M M;V1I9GEI;F<@=&AE(&5N=&ET>2!B;V1Y+"!A;F0@25-!4$D@1FEL=&5R(&ES M(&YO="!T:&4-"G!R969E6]U2!B;V1Y+"!)25,@:6UP97)S;VYA=&EO;B!T;VME;BP@86YD('-O;64@ M4V5R=F5R5F%R:6%B;&4-"G9A;'5E2!W:71H;W5T('1H92!C:&EL9"!54DP@6]U(&EN('1H870@;6%N;F5R+B @5V4@9&ED;B=T(&AA=F4@=&AI2!I;F-O;6EN9R!R97%U97-T M2!B;V1Y*2 M+2!W:&EC:"!D;V5S;B=T#0IW M;W)K('=I=&@@4U-,+"!31E].3U1)1EE?4%)%4%)/0U](14%$15)3(&9I;'1E M6]U(&-O;W)D:6YA=&4@=VET:"!31E]. M3U1)1EE?05542$5.5$E#051)3TXL(&%N9"!S;R!O;BX-"DA315]215%?15A% M0U]54DP@:&%S(&YO;F4@;V8@=&AO6]U('-I;7!L92!C:&%N9V4-"G1H92!E;G1I2!T M:&EN9W,@:6X@24E3-2!#;VUP871I8FEL:71Y($UO9&4@*'1H870G6]U('=A M;G0@=&\@=')E870@2%144"!L;V=I8V%L;'DL('-U8V@@87,@55),+"!H96%D M97)S+"!E;G1I='DM8F]D>2P@>6]U#0IC86X@96ET:&5R(&1O('1H92!H87)D M('=O71H:6YG(&EM<&]R=&%N M="!O=&AE6]U65R(&YO65R0T*86-C97!T86)L92!B>2!T:&4@8V]N2!I2!F;W(@;6]D:69Y:6YG('1H92!E;G1I='D@8F]D>2X-"@T*0G5T(&UY M(&UA:6X@<75E'!O M