> The HTTP API provides developers with a > low-level interface to the server side of the > HTTP functionality as defined in RFC 2616. > The API allows the application to receive > HTTP requests directed to URLs of interest > to it, and send HTTP responses. For sending > dynamic responses, however, the ISAPI or > ASP.NET interfaces are a better choice than > the HTTP API.
ASP.NET is a better choice for a web application because it's easier to be used by a programer.:) However ASP.NET uses IIS 6 and IIS 6 uses HTTP API so nothing will be faster. But Apache HTTPD is a web server not a web application. Reply to the long quote about cache: In fact HTTP has a cache but you have to store buffers in the cache and you have to make HTTP API to send the cached buffer. It will not send cached response automatically. > > only small server, > > > > >Not a real new big > > > > >business web server. But may be a server > > > > >for the one man shop > Yes HTTP.SYS may be fine as a > "stand alone" home office web > server (via the newer .NET > Framework class) but for a high > demand place? > > HTTP.SYS needs more... > HTTP.SYS is a device > (a very helpful device) HTTP API is not a web server. It's only a listener and does some preporcessings. A web server is more than a listener it has to process the request and server the response as well. And this thread is about using HTTP API as a listener in Apache HTTPD instead of (in fact by the side of) Winsock and not about using HTTP API as a web server instead of Apache HTTPD. And of course we don't want to use HTTP API through .NET Framework interfaces as we can use it using native C faster. > The HTTP API does not perform client or > server authentication based on the contents > of the HTTP request headers. Any authentication > that is required must be implemented by the > application. This has to be done by the web server. > The HTTP API does not support > WOW64 on 64-bit machines. No problem, Apache HTTPD can work without HTTP API, it could be only an extra feature on Windows in addition to traditional Winsock listening. > The HTTP API does not support > logging of HTTP requests and responses. It doesn't have to do it. Nobody said that HTTP API is a web server, I think only the author of this article though that it is a web server. It can't serve or response any kind of requests nor will server static files from file sistem or from the cache. You have to write the web server logic, it provides only the url, the headers and the entity body. However it can log errors that are not routed to applications: http://support.microsoft.com/default.aspx?scid=kb;en-us;820729 According to these articles: http://www.microsoft.com/resources/documentation/windowsserv/2003/standard/proddocs/en-us/log_custommodules.asp Look for "Does the HTTP.sys caching still log the hits?": http://support.microsoft.com/default.aspx?scid=%2Fservicedesks%2Fwebcasts%2Fen%2Fwc112002%2Fwct112002.asp I think that HTTP.SYS does the full logging for IIS 6, but it is another undocumented feature that can be used only by IIS 6. > The HTTP API does not chunk outgoing > HTTP responses. The application must > implement response chunking if it is needed. This is already implemented in Apache HTTPD, no problem. > Perhaps with programs that use > the new APIs from the Firewall > and the HTTP.SYS device. As I know HTTP.SYS is independent from Windows Firewall, but please let me know if I'm wrong. > > If all port is open > > (it's a really huge number of > > open ports, but why not:)) > > Please read why not to have > open ports elsewhere. :) It's true, however it's not safer nor unsafer using HTTP API than using Winsock to listen on ports. Both of them can be used with firewalls. Listening is a better word for this as opening ports is used for firewalls. Sincerely, Kornel
