Windows HTTP API

[Korn�l P�l <ko...@hotmail.com>]

Hi!

Microsoft describes http.sys as the kernel mode cache of IIS 6, however it's
kernel mode HTTP listener with cache for any application.

Using http.sys Apache HTTPD could be used with IIS 6 on Windows sharing the
same port and IP address. I think this is a good thing if you want to host
more web sites using different server software on the same server.

Directory names can also be specified in addition to host names, thus
different directories with the same host can be served by different server
software.

It has a public user mode interface, httpapi.dll, and it used by IIS 6 as
well, so anybody can use the same functionality.

And of course Apache HTTPD could use the cache functionality of http.sys.

http.sys is a core operating system component, it's on the system without
installing IIS 6. It's supported by Windows Server 2003 and will be included
in the upcoming Windows XP SP2.

I think you should consider implementing HTTP API in Apache HTTPD as it has
a lot of possibilities.

More information about HTTP API is available in Platform SDK:
http://msdn.microsoft.com/library/en-us/http/http/http_api_start_page.asp

Sincerely,
Korn�l

Re: Windows HTTP API

[Korn�l P�l <ko...@hotmail.com>]

>>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.

You are absoultely right.
I just wanted to say that filters that require raw request data shoul be
ignored and only filters that use structured data should be kept.

>>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.

OK.:)
I thought you want to show similarities between HTTP API SSL and sockets,
but you wanted to show that netware supports SSL natively at socket level.

Sincerely,
Kornel

Re: Windows HTTP API

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

At 04:17 PM 6/21/2004, Kornél Pál 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

Re: Windows HTTP API

[Jeff White <jl...@earthlink.net>]

Before one moves on to what I was
told was the real topic of this thread...

> "Kornél Pál"
> however this topic is about using
> HTTP API in Apache HTTPD.

First let's clear up some ideas. :)

Forgetting about logging for now.

> WRowe
> I thought the entire point was that it

It being the HTTP.SYS service...

> was smart enough to act like a
> squid-like low level in-kernel cache?
> If not I'm disappointed :)
>

Yes I believe it is...

So does everyone agree with the below:

That once a file is HTTP.SYS cached

(for now we do not care how or why
only that the file is cached),

that once a file is cached in the service
cache of HTTP.SYS, from there on until
the cached file has reached it's set timed
out period or the HTTP.SYS is stopped,
then only the HTTP.SYS service will handle
the file and send the file, as a cached response

(no other process is needed, whether that
process be IIS or Apache or a .NET Framework
http aware process)?

Agreed?

Now clearing up other ideas:

> "Kornél Pál"
> It's a reply to a quotation that said HTTP API
> is not a good choice for a "high demand place"
> as it lacks a lot of feauters. But the author of this
> quotation thought that HTTP API is a web server.

And

> "Kornél Pál"
> HTTP API is not a web server.

Correct....usually there is another http
aware process involved, but a little FYI:

Windows now means .NET Framework...
(yes old Windows http ways are still available
Winsock and all, but newer http ways are
HTTP.SYS and .NET Framework)

Yes both old and new can be used together
if one does the work.....

Anyway this is why I say, with the "newer"
Windows ways, (.NET Framework usage),
it can be used now (beta) and soon (I hope
with the final Windows XP SP2 release, but
who knows) as a simple web server.

(via .NET Framework)

When the .NET Framework class was
written, the class includes the code
from HTTP.SYS, making HTTP.SYS a
.NET Framework callable web server
or a HTTP.SYS function caller for another
http aware process. Read on....

In .NET Framework (soon out):

HttpListener class  (uses HTTP.SYS)
Defined as a simple web server....

One that can self-host or be hosted
by another server (http aware process)...

Windows XP SP2 and higher...

This is what I meant by "stand alone"
( yes for a quick and "dumb" web server)
but, HTTP API by itself ( using C/C++ or
PInvoke with .NET Framework without
HttpListener) always needs another process,
unless serving cached files (put there
by another http aware process).

So right now I would not use .NET Framework's
HttpListener (a HTTP.SYS web server), for a
"high demand business" without adding other
classes but yes HTTP.SYS is or is not (user's
choice) in the .NET Framework, a web server
and maybe great for those quick http actions,
for say grandpa's pictures and other such quick
business needs.

(Yes under the covers HTTP.SYS is a separate
service combined with others actions to make
it a simple .NET Framework web server)

So that was the stand alone web server
thought.... via .NET Framework... Let it go
if you must, but be aware of it.

There is a lot going on in .NET Framework,
even with (and for) Apache usage, but that
is for another thread...

Jeff

Re: Windows HTTP API

[Korn�l P�l <ko...@hotmail.com>]

> >ASP.NET is a better choice for a web application because it's easier to
be
> >used by a programer.:)
> Religious discussions are off-topic on this list...

It wasn't only my opinion it was an aswer to a quotation or an
interpretation of it that said ASP.NET is better than HTTP API. It's true
for web applications because of the above however this topic is about using
HTTP API in Apache HTTPD. And of course ASP.NET and HTTP API are quite
different things.

> >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.
>
> Yes but you can plug ASP.NET into any server, including Apache.  Not
> trivial, but a project in incubation (waiting for my SVN skill to increase
> to the point that it starts out as the sole version control system for
> the subproject) will offer this as open-source with Apache.  Actually
> anyone could create the thunks required to host ASP.NET.  Heck, there is a
command line host ;)

It was a reaction to the same quotation that said it's better to use ASP.NET
than HTTP API.

I've tried to connect Apache HTTPD and Microsoft ASP.NET on Win32, I've done
some work on .NET side however I'm not experienced enough in Apache HTTPD
enough to do the other side. But you didn't said which side have you done
and on which side do you require thunks.
I can help in the .NET side of the implementation but not too much in an
Apache HTTPD module.

> >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.
>
> I thought the entire point was that it was smart enough to act like a
> squid-like low level in-kernel cache?  If not I'm disappointed :)

It's a reply to a quotation that said HTTP API is not a good choice for a
"high demand place" as it lacks a lot of feauters. But the author of this
quotation thought that HTTP API is a web server. A web has to have cache and
authentication features however a HTTP listener like HTTP API don't has to
and it's better if it don't provides to can be used widely. The kernel mode
cache that it provides (I don't know squid deeply, so I can't answer you
question) is better for a web server than sending responses automatically
from the cache.

And of couse it's cache is very fast, but you have to tell it the identifier
of the cached data to can be sent. I think in this situation this way is
better than automatic responses from the cache.

Sincerely,
Kornel

Re: Windows HTTP API

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

>ASP.NET is a better choice for a web application because it's easier to be
>used by a programer.:)

Religious discussions are off-topic on this list...

>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.

Yes but you can plug ASP.NET into any server, including Apache.  Not
trivial, but a project in incubation (waiting for my SVN skill to increase 
to the point that it starts out as the sole version control system for 
the subproject) will offer this as open-source with Apache.  Actually 
anyone could create the thunks required to host ASP.NET.  Heck, there is a command line host ;)

>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.

I thought the entire point was that it was smart enough to act like a
squid-like low level in-kernel cache?  If not I'm disappointed :)

Bill  

Re: Windows HTTP API

[Korn�l P�l <ko...@hotmail.com>]

> 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

Re: Windows HTTP API

[Jeff White <jl...@earthlink.net>]

From: "Kornél Pál"

> > > I have to say you are wrong.

> >
> > Okay I often am but where?   :)

>
> I've quoted the lines in your are wrong in my opinion.:)
> Summarized:
> only static files,

I said:
"HTTP.SYS is for quick static responses"

<quote>

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.

</quote>

About HTTP API
http://msdn.microsoft.com/library/en-us/http/http/about_http_api.asp

Kernel mode HTTP.SYS usually receives
requests and routes them to another user
mode process, unless there is a response
stored in the kernel mode HTTP.SYS cache.

An example of  HTTP.SYS using another
process and caching:

<quote>

Does a page get cached or not?

IIS 6.0 has a great response caching
feature implemented in the kernel-mode
http.sys driver.  Depending on the app
and the load characteristics, it can greatly
improve application performance for both
static and dynamic pages by caching html
responses in kernel mode.  The performance
improvement comes primarily from eliminating
the transitions from kernel to user mode
typically needed to service a request.

Response caching works with static files,
as well as with dynamic content in ASP and
ASP.NET.  For ASP.NET, you enable caching
through the configuration directive:

    <%@ OutputCache Location="Server" %>

But how does http.sys determine whether
to cache a page?  One way would be to cache
each page requested in FIFO order.  So once
the cache fills up, then the oldest cache entry
would be the first to drop off the list.  However,
it's common for a page to be requested only
infrequently, so this would fill the cache
unnecessarily.

Instead, pages are cached only if they are
requested twice within a configurable activity
period, whose default is 10 seconds.

For example, if you have an application
that serves stock quotes (this is essentially
what http://quotes.nasdaq.com, which runs
IIS 6 does) and you're commonly getting
requests for quotes for MSFT.

Once cached, the response is returned
directly from the kernel-mode cache.  But
what about the price of the stock, which
changes?  The attribute 'Duration' allows
you to indicate how long to cache a
response.  So if you set Duration=10, you're
keeping the response in the cache for
10 seconds.

</quote>

> 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)

<quote>

The HTTP API does not support the
following functionality:

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.

The HTTP API does not support
WOW64 on 64-bit machines.

The HTTP API does not support
logging of HTTP requests and responses.

The HTTP API does not chunk outgoing
HTTP responses. The application must
implement response chunking if it is needed.

</quote>

HTTP API Features
http://msdn.microsoft.com/library/en-us/http/http/http_api_features.asp

> improved security

> > > >and may be for security
> > > >of open ports, etc. :)

What is the HTTP.SYS device's
default binding in Windows XP SP2?

What is the Windows Firewall default
in Windows XP SP2?

Developers (and users) need to be
aware of both of these new controllers
as Windows system parts.

Perhaps with programs that use
the new APIs from the Firewall
and the HTTP.SYS device.

Or perhaps the user will need to use
the config tools for these devices
(or a program with rights to use these
config tools).

> 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.  :)

Jeff

Re: Windows HTTP API

[Korn�l P�l <ko...@hotmail.com>]

> > >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.
>
> Okay I often am but where?   :)

I've quoted the lines in your are wrong in my opinion.:)
Summarized:
only static files, only small server, improved security

> So I believe you are saying I am wrong with
> "HTTP.SYS is for quick static responses."?
>
> Perhaps this
> HTTP.SYS "main idea and heart" is for quick
> static responses.

It could be designed for static responses but it has to be at least as fast
as Winsock is in dynamic responses as it does the same, but can be faster in
dynamic responses as well as does some preprocession in kernel mode and
don't trasfer invalid data to user mode.

> > And I think HTTP API doesn't provides any
> > extra security.
> >
>
> Okay for starters, what happens when
> on Windows XP SP2 HTTP.SYS gets
> an invalid request when controlling all
> ports?

HTTP.SYS doesn't includes a firewall, but Windows Firewall (and any other
firewall) can be used with any HTTP server.
If all port is open (it's a really huge number of open ports, but why not:))
or if a single port is open on all IPs or a single port is open on a single
IP it has to be request (including invalid ones) has to be handled the same
way by the server.

You are right that HTTP.SYS filters invalid requests but a public HTTP
server has to filter all the requests that it cannot process or are invalid.

> Or a request for access on an open
> port but nothing defined with HTTP.SYS
> for that open port?

In any other cases a port will only be opened if neeeded. But in the case if
a prot is listenig but no requests will be accepted is only a processor and
network overhead.

> Now compare the difference with
> a computer with an open port but
> no HTTP.SYS on Windows XP SP1.
>
> See any big security differences?

Sorry, but I don't see them.

Sincerely,
Kornel

Re: Windows HTTP API

[Jeff White <jl...@earthlink.net>]

From: "Kornél Pál"

> 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.

Okay I often am but where?   :)

> 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.

So I believe you are saying I am wrong with
"HTTP.SYS is for quick static responses."?

Perhaps this
HTTP.SYS "main idea and heart" is for quick
static responses.

If not the above, I do not understand,
please explain...

> And I think HTTP API doesn't provides any
> extra security.
>

Okay for starters, what happens when
on Windows XP SP2 HTTP.SYS gets
an invalid request when controlling all
ports?

Or a request for access on an open
port but nothing defined with HTTP.SYS
for that open port?

Now compare the difference with
a computer with an open port but
no HTTP.SYS on Windows XP SP1.

See any big security differences?

Jeff

Re: Windows HTTP API

[Korn�l P�l <ko...@hotmail.com>]

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 \<V]M96]N94!O;FQI;F4N;6EC
M<F]S;V9T+F-O;3X-"E)E9F5R96YC97,Z(#Q/2V=W:5(C545(02XS,#$R0'1K
M,FUS9G1N9W Q,RYP:'@N9V)L/@T*4W5B:F5C=#H@4F4Z($E)4R!A;F0@2%14
M4"!!4$D-"D1A=&4Z(%-A="P@,3D@2G5N(#(P,#0@,#,Z,#(Z,#4@+3 W,# -
M"DQI;F5S.B Q-S8-"E@M4')I;W)I='DZ(#,-"E@M35--86EL+5!R:6]R:71Y
M.B!.;W)M86P-"E@M3F5W<W)E861E<CH@36EC<F]S;V9T($]U=&QO;VL@17AP
M<F5S<R V+C P+C(X,# N,30P.0T*6"U-:6UE3TQ%.B!0<F]D=6-E9"!">2!-
M:6-R;W-O9G0@36EM94],12!6-BXP,"XR.# P+C$T,#D-"DUE<W-A9V4M240Z
M(#PC-DEW86=E5D5(02XS-30P0%1+,DU31E1.1U Q,2YP:'@N9V)L/@T*3F5W
M<V=R;W5P<SH@;6EC<F]S;V9T+G!U8FQI8RYI;F5T<V5R=F5R+FEI<RQM:6-R
M;W-O9G0N<'5B;&EC+G!L871F;W)M<V1K+FEN=&5R;F5T+G-E<G9E<BYI<V%P
M:2UD978-"DY.5% M4&]S=&EN9RU(;W-T.B!T:61E,3 X+FUI8W)O<V]F="YC
M;VT@,C W+C0V+C(R."XQ-@T*4&%T:#H@5$LR35-&5$Y'4# X+G!H>"YG8FPA
M5$LR35-&5$Y'4#$Q+G!H>"YG8FP-"EAR968Z(%1+,DU31E1.1U P."YP:'@N
M9V)L(&UI8W)O<V]F="YP=6)L:6,N<&QA=&9O<FUS9&LN:6YT97)N970N<V5R
M=F5R+FES87!I+61E=CHU,S8S(&UI8W)O<V]F="YP=6)L:6,N:6YE='-E<G9E
M<BYI:7,Z,S$R-3,W#0H-"E1H86YK<R!F;W(@=&AE('%U97)Y+B @22=V92!A
M8W1U86QL>2!N;W0@<V5E;B!E:71H97(@;V8@=&AE<V4@2T)S('5N=&EL(&YO
M=RP-"F)U="!)(&-A;B!T96QL('EO=2!T:&%T('1H92!+0B!I<R!W<F]N9R!T
M;R!S87D@=&AA="!34TP@:6X@24E3-B!U<V5S('1H90T*4T9?3D]424997U)%
M041?4D%77T1!5$$@9FEL=&5R(&YO=&EF:6-A=&EO;B!T;R!F=6YC=&EO;BX@
M($ET(&1O97,@;F]T+B @4U-,#0II;B!)25,V(&ES(&YO="!A;B!)4T%022!&
M:6QT97(N("!))VT@86QS;R!G;VEN9R!T;R!T<GD@=&\@8VQA<FEF>2!T:&4@
M:6YF;PT*:6X@,S$Q.#4R(&)E8V%U<V4@22!T:&EN:R!T:&4@=7-A9V4@;V8@
M=&AE('=O<F1S(")214%$7U)!5U]$051!(B!A;F0-"B)31E].3U1)1EE?4D5!
M1%]205=?1$%402(@87)E('%U:71E(&5R<F%T:6,O8V]N9G5S:6YG+"!A;F0@
M22=M(&%L<V\@9V]I;F<@=&\-"G=O<FL@=&\@9V5T('1H97-E($M"<R!F:7AE
M9"X-"@T*5&AE(&-R=7@@;V8@=VAA="!I<R!G;VEN9R!O;B!I<R!T:&ES("AR
M;W5G:"!C;VYC97!T=6%L(&1E=&%I;',I.@T*#0I(5%10+E-94R!B87-I8V%L
M;'DZ#0HQ+B!R96%D<R!D871A(&9R;VT@=&AE(&YE='=O<FMI;F<@;&%Y97(-
M"C(N('!A<G-E<R!I= T*,RX@9&]E<R!S;VUE(&)A<VEC($A45% M;&5V96P@
M=F%L:61A=&EO;G,@86-C;W)D:6YG('1O($A45% O,2XQ('-P96,-"C0N(')O
M=71E<R!I="!T;R!A('5S97(@;6]D92!P<F]C97-S(&9O<B!R97%U97-T(&5X
M96-U=&EO;BX-"@T*06QL(&]F('1H97-E('-T97!S(&AA<'!E;B!I;B!K97)N
M96P@;6]D92X-"@T*5'=O(&-O;F-E<'1S(&UU8VL@=VET:"!T:&ES(&%R8VAI
M=&5C='5R92!I;B!)25,@+2T@4U-,(&%N9 T*4T9?3D]424997U)%041?4D%7
M7T1!5$$@9FEL=&5R<RX@($)O=&@@8V]N8V5P=',@<F5Q=6ER92!A8V-E<W,@
M=&\@=&AE(')A=PT*9&%T82!S=')E86T@<')I;W(@=&\@:70@8F5I;F<@<&%R
M<V5D(&)Y($A45% N4UE3+"!M96%N:6YG('1H870@:70@:&%S('1O(&)E#0IS
M;VUE:&]W(&EN=&5R:F5C=&5D(&)E='=E96X@<W1E<',@(S$@86YD(",R(&%B
M;W9E+B @4VEN8V4@=V4@8V%N;F]T(&IU<W0-"F5X96-U=&4@97AI<W1I;F<@
M4T9?3D]424997U)%041?4D%77T1!5$$@9FEL=&5R<R H=VAI8V@@87)E('5S
M97(@;6]D92!$3$QS*0T*:6X@:V5R;F5L(&UO9&4L('1H:7,@;65A;G,@=&AA
M="!(5%10+E-94R!W:6QL(&YE960@=&\@:&%V92!S;VUE(")M96-H86YI<VTB
M#0IT;R!S=')E86T@<F%W(&1A=&$@9G)O;2 C,2!I;G1O(&$@=7-E<B!M;V1E
M('!R;V-E<W,L(&QE="!I="!M=6YG92!T:&4@9&%T80T*:&]W979E<B!I="!W
M86YT<RP@86YD('1H96X@<F5T=7)N('1H92!D871A('1O($A45% N4UE3(&EN
M(&ME<FYE;"!M;V1E(&9O<B C,@T*86YD(&-O;G1I;G5E(')E<75E<W0@:&%N
M9&QI;F<N("!.965D;&5S<R!T;R!S87DL('1H:7,@:7,@<75I=&4@82!P<FEV
M:6QE9V5D#0IO<&5R871I;VXN#0H-"E1H=7,L(&)O=&@@4U-,(&%N9"!31E].
M3U1)1EE?4D5!1%]205=?1$%402!R96QY(&]N('1H:7,@(FUE8VAA;FES;2(@
M=&\-"G-T<F5A;2!R87<@9&%T82!F<F]M(&ME<FYE;"!M;V1E(&EN=&\@=7-E
M<B!M;V1E(&%N9"!B86-K+"!P<FEO<B!T;R!S=&5P(",R+@T*3F]W+"!(5%10
M+E-94R!H87!P96YS('1O(&]N;'D@<W5P<&]R="!T:&ES(")M96-H86YI<VTB
M(&9O<B!A(%-)3D=,12!U<V5R#0IM;V1E('!R;V-E<W,@9F]R('9A<FEO=7,@
M=&5C:&YI8V%L(')E87-O;G,@*&EN8VQU9&EN9R!T:&4@9F%C="!T:&%T(&AO
M<W0-"FAE861E<G,@87)E(&YO="!K;F]W;B!;4T9?3D]424997U)%041?4D%7
M7T1!5$$@8V]U;&0@8VAA;F=E(&ET(&%S('=E;&Q=*2X-"@T*5&AE<F5F;W)E
M+"!A;&P@<F5Q=65S=',@=&AA="!R97%U:7)E(%-33"!A;F0O;W(@4T9?3D]4
M24997U)%041?4D%77T1!5$$@9V\-"G1H<F]U9V@@=&AI<R!M96-H86YI<VT@
M+2T@9FER<W0L('1H92!D871A(&ES(')E860@:6X@:V5R;F5L(&UO9&4L('1H
M96X-"G1R86YS:71I;VYE9"!I;G1O('5S97(@;6]D92!T;R!M=6YG92]D96-R
M>7!T+"!T:&5N('1R86YS:71I;VYE9"!B86-K(&EN=&\-"FME<FYE;"!M;V1E
M('1O('!A<G-E+"!A;F0@;&%T97(@<VAU='1L960@8F%C:R!I;G1O('5S97(@
M;6]D92!T;R!E>&5C=71E+@T*3F]T('9E<GD@<')E='1Y+"!B=70@:70@=V]R
M:W,@86YD(&ES(&YO="!T:&4@9&5F875L="!C87-E+@T*#0I.;W<L('=H870@
M9&]E<R!T:&ES(&AA=F4@86YY=&AI;F<@=&\@9&\@=VET:"!)25,V(&UO9&5S
M/R @5V5L;"P@:6X@24E3-0T*0V]M<&%T:6)I;&ET>2!-;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<F]C97-S('1O(&AA;F1L92!T:&4@<F%W(&1A=&$@<VEN8V4@
M8F]T:"!)4T%022!&:6QT97)S(&%N9"!34TP@;F5E9',-"G1O(')U;B!I;B!T
M:&%T('!R;V-E<W,@86YY=V%Y(&9O<B!C;VUP870@<F5A<V]N<RP@86YD('-O
M#0I31E].3U1)1EE?4D5!1%]205=?1$%402!I<R!C;&5A;FQY('-U<'!O<G1E
M9"X-"@T*5&AI<R!A;&P@8G)E86MS(&1O=VX@:6X@24E3-B!7;W)K97(@4')O
M8V5S<R!)<V]L871I;VX@36]D92!B96-A=7-E#0II;F1I=FED=6%L('<S=W N
M97AE(&QO860@=&AE:7(@;W=N($E305!)($9I;'1E<G,@+2T@<V\@;75L=&EP
M;&4@:6YS=&%N8V5S(&]F#0IT:&4@<V%M92!&:6QT97(@1$Q,(&-A;B!B92!I
M;B!M96UO<GD@:6X@<V5P87)A=&4@=S-W<"YE>&4@+2T@86YD('=H870-"FAA
M<'!E;G,@:68@=&AI<R!&:6QT97(@=7-E<R!31E].3U1)1EE?4D5!1%]205=?
M1$%402 _("!792!N;W<@:&%V92 ^,0T*<')O8V5S<R!W86YT:6YG('1H92!R
M87<@9&%T82!R;W5T960@=&\@:70L(&)U="!(5%10+E-94R!C86X@;VYL>2!R
M;W5T92!T;R!A#0IS:6YG;&4@<')O8V5S<RX@($YO=RP@>6]U(&UA>2!A<F=U
M92!T:&%T('=E('-H;W5L9"!H879E('-P=6X@=7 @;VYE('-I;F=L90T*<W5R
M<F]G871E('!R;V-E<W,@=&\@:&]S="!A;&P@25-!4$D@1FEL=&5R<R!A;F0@
M4U-,+"!B=70@=&AI<R!D97-I9VX-"F1E<W1R;WES(%=O<FME<B!0<F]C97-S
M($ES;VQA=&EO;B!-;V1E("TM('1H:7,@<W5R<F]G871E('!R;V-E<W,@:7,@
M;VYC90T*86=A:6X@82!S:6YG;&4@<&]I;G0@;V8@9F%I;'5R92!F;W(@86QL
M('<S=W N97AE(&%N9"!I<R!N;R!B971T97(@=&AA;B!T:&4-"DE)4S4@<')O
M8V5S<R!M;V1E;" H<W5B<W1I='5T92!I;F5T:6YF;RYE>&4@9F]R('1H92!S
M:6YG;&4@<W5R<F]G871E('!R;V-E<W,-"F%N9"!Y;W4@9V5T('1H92!S86UE
M(&QO;VMI;F<@<&EC='5R92DN("!!;&P@;V8@=&AE(&]T:&5R(&1E<VEG;G,@
M870@=')Y:6YG#0IT;R!E;F%B;&4@4T9?3D]424997U)%041?4D%77T1!5$$@
M:6X@24E3-B!7;W)K97(@4')O8V5S<R!)<V]L871I;VX@36]D92!H879E#0IO
M=&AE<B!S:6UI;&%R(&)U="!F871A;"!F;&%W<RX-"@T*4V\L('1H92!W:&]L
M92!31E].3U1)1EE?4D5!1%]205=?1$%402!C;VYC97!T(&IU<W0@9&]E<R!N
M;W0@=V]R:R!W:71H(%=O<FME<@T*4')O8V5S<R!)<V]L871I;VX@36]D92P@
M86YD(&AE;F-E('=E(&1I9"!T:&4@;F5X="!B97-T('1H:6YG("TM(&1I<V%B
M;&4@=&AE#0IB<F]K96X@8V]N8V5P="P@8G5T(&=I=F4@82!B971T97(@86QT
M97)N871I=F4@=&AA="!A;&QO=W,@.3DN.24@;V8@<&5O<&QE('1O#0ID;R!W
M:&%T('1H97D@86-T=6%L;'D@=V%N=&5D('1O(&1O(&%N9"!L:79E('=I=&@@
M8G)E86MI;F<@=&AA=" P+C$E.@T*,2X@3&5T(%-33"!H879E('1H92!L;VYE
M(')A=R!D871A(")M96-H86YI<VTB(&%N9"!H;W-T(&ET(&EN(&QS87-S+F5X
M92!T;PT*:&%V92!O;FQY(&]N92!P<F]C97-S(&EN=F]L=F5D(&EN(&1E8W)Y
M<'1I;F<O96YC<GEP=&EN9R!D871A#0HR+B!$:7-A8FQE(%-&7TY/5$E&65]2
M14%$7U)!5U]$051!(&EN($E)4S8@5V]R:V5R(%!R;V-E<W,@27-O;&%T:6]N
M($UO9&4-"C,N($UA:V4@<W5R92!T:&%T('1H92!N97<@24E3-B!F96%T=7)E
M+"!(4T5?4D517T5814-?55),+"!C86X@=&%K92!C87)E(&]F#0IT:&4@.3DN
M.24@=7-A9V4@8V%S92!O9B!31E].3U1)1EE?4D5!1%]205=?1$%402 H=VAI
M8V@@:7,@=&AE(&UU;F=E('1H90T*:6YC;VUI;F<@<F5Q=65S="P@:6X@<&%R
M=&EC=6QA<B!03U-4(&5N=&ET>2!B;V1Y(&9R;VT@1D]237,I#0H-"D9R;VT@
M;7D@<&5R<W!E8W1I=F4L('1H92!M86EN('5S97)S('1H870@87)E(&QE9G0@
M:6X@=&AE(&-O;&0@8GD@=&AI<PT*9&5C:7-I;VX@87)E('1H92!P96]P;&4@
M=VAO('=R;W1E('!R;W!R:65T87)Y(&]P87%U92!S=')E86T@9FEL=&5R<RP@
M<W5C:"!A<PT*8W5S=&]M(&5N8W)Y<'1I;VXO8V]M<')E<W-I;VXL(&%N9"!W
M86YT('1O(')U;B!I;B!)25,V(%=O<FME<B!0<F]C97-S#0I)<V]L871I;VX@
M36]D92X@(%1H97)E(&%R92!N;R!S;VQU=&EO;G,@:6X@=&AI<R!C87-E(&]T
M:&5R('1H86X@24E3-0T*0V]M<&%T:6)I;&ET>2!-;V1E+@T*#0I9;W5R('-U
M9V=E<W1I;VX@;V8@(BXN+DEF('EO=2!D;VXG="!W86YT('1O(&UO9&EF>2!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@<F5J96-T960@:70N("!790T*86QR96%D>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!R969E<G)E9"!)25,@97AT96YS:6]N(&UE8VAA;FES;2 H
M25-!4$D@17AT96YS:6]N(&ES(&9A<B!R:6-H97(@86YD#0ID971E<FUI;FES
M=&EC*2P@<V\@=V4@8VAO<V4@;F]T('1O(&%D9"!A;GD@;F5W(&9I;'1E<B!N
M;W1I9FEC871I;VYS+@T*#0I3;RP@:68@>6]U<B!W:&]L92!R96%S;VX@9F]R
M(%-&7TY/5$E&65]214%$7U)!5U]$051!(&ES('1O(&=E="!A8V-E<W,@86YD
M#0IC;VYT<F]L(&]F('1H92!I;F-O;6EN9R!R97%U97-T+"!T:&5R92!A<F4@
M8F5T=&5R(&%N9"!S=7!P;W)T960@=V%Y<R!O9@T*9&]I;F<@=&AI<R!I;B!)
M25,V+B @0V]N9FEG=7)E(&$@25-!4$D@17AT96YS:6]N(&%S(&$@5VEL9&-A
M<F0@07!P;&EC871I;VX-"DUA<'!I;F<@86YD('5S92!(4T5?4D517T5814-?
M55),+B @66]U('=I;&P@;F]T:6-E('1H870@2%-%7U)%45]%6$5#7U523"!I
M<PT*86)L92!T;R!M;V1I9GD@=&AE(&5N=&ER92!R97%U97-T('1H870@:7,@
M<')O8V5S<V5D(&)Y($E)4RP@:6YC;'5D:6YG(%523"P-"FAE861E<G,L(&5N
M=&ET>2!B;V1Y+"!)25,@:6UP97)S;VYA=&EO;B!T;VME;BP@86YD('-O;64@
M4V5R=F5R5F%R:6%B;&4-"G9A;'5E<R H;&EK92!!551(7U194$4L($%55$A?
M55-%4BP@3$]'3TY?55-%4BP@971C*2P@86YD('=H96X@8V]N9FEG=7)E9"!A
M<PT*82!7:6QD8V%R9"!!<'!L:6-A=&EO;B!-87!P:6YG+"!I="!G971S(&9I
M<G-T(&-R86-K(&%T(&%L;"!T:&4@<F5Q=65S=',@86YD#0IC86X@9FEL=&5R
M+W)E9&ER96-T(&%S(&ET('!L96%S97,N($A315]215%?15A%0U]54DP@:7,@
M979E;B!A8FQE('1O(&-O;G-U;64-"F%N9"!O=&AE<G=I<V4@;75N9V4@=&AE
M(&5N=&ER92!E;G1I='D@8F]D>2!W:71H;W5T('1H92!C:&EL9"!54DP@<F5A
M;&EZ:6YG#0II="P@86YD(&ET(&ES(&9U;&QY(&-O;7!A=&EB;&4@=VET:"!3
M4TPN#0H-"E1H:7,@:7,@8F%S:6-A;&QY('=H870@;6]S="!P96]P;&4@=V%N
M="!T;R!D;R!O;B!T:&4@<V5R=F5R+"!A;F0@24E3-B!G:79E<PT*:70@=&\@
M>6]U(&EN('1H870@;6%N;F5R+B @5V4@9&ED;B=T(&AA=F4@=&AI<R!I;B!P
M<FEO<B!V97)S:6]N<R!O9B!)25,L('-O#0IP96]P;&4@:&%V92!H860@=&\@
M:&%C:R!T;V=E=&AE<B!&:6QT97)S('5S:6YG(%-&7TY/5$E&65]214%$7U)!
M5U]$051!('1O#0IB=69F97(@86YD(&UO9&EF>2!I;F-O;6EN9R!R97%U97-T
M<R H:6YC;'5D:6YG(&5N=&ET>2!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
M<B!A;F0@8V]M8F\@25-!4$D@17AT96YS:6]N(&EF#0IY;W4@:G5S="!W86YT
M('1O(&-H86YG92!54DPL(&AE861E<G,L(&%N9"!F=61G92!S;VUE(%-E<G9E
M<E9A<FEA8FQE('9A;'5E<PT*:68@>6]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@=&AO<V4@:&%C:WD@;&EM:71A=&EO;G,@+2T@
M>6]U('-I;7!L92!C:&%N9V4-"G1H92!E;G1I<F4@<F5Q=65S="!T:&%T(&=E
M=',@97AE8W5T960@8GD@24E3(&%N9"!T:&5N('1E;&P@24E3('1O(&5X96-U
M=&4-"FET+@T*#0I9;W4@8V%N('-T:6QL(&1O(&%L;"!T:&]S92!H86-K>2!T
M:&EN9W,@:6X@24E3-2!#;VUP871I8FEL:71Y($UO9&4@*'1H870G<PT*=VAA
M="!C;VUP871I8FEL:71Y(&ES(&9O<BDL(&)U="!W92!H:6=H;'D@9&ES8V]U
M<F%G92!I="!I;B!)25,V(%=O<FME<@T*4')O8V5S<R!)<V]L871I;VX@36]D
M92!B96-A=7-E('1H97)E(&%R92!B971T97(@86QT97)N871I=F5S+B @268@
M=V4@9&ED;B=T#0IH879E(&)E='1E<B!A;'1E<FYA=&EV97,L('=E('=O=6QD
M(&AA=F4@;6%D92!S=7)E('1H870-"E-&7TY/5$E&65]214%$7U)!5U]$051!
M(')E;6%I;F5D('1H92!S86UE(&EN(&%L;"!M;V1E<RX-"@T*268@>6]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('=O<FL@;V8@<&%R<VEN9R!T:')O=6=H(&1A=&$@<W1R96%M(&%S('=I=&@@
M=&AE($%027,-"GEO=2=R92!A<VMI;F<@86)O=70L(&]R('EO=2!C86X@=7-E
M('1H92!L;V=I8V%L($%022!O9B!(4T5?4D517T5814-?55),('1O#0IM;V1I
M9GD@=&AE(&5X86-T('-A;64@=&AI;F<@<')I;W(@=&\@24E3(&5X96-U=&EN
M9R!T:&4@<F5Q=65S="X@($D@;&5A=F4@:70-"G5P('1O('EO=2!T;R!D96-I
M9&4@=VAI8V@@:7,@96%S:65R(&%N9"!M86ME<R!M;W)E('-E;G-E+@T*#0I0
M97)S;VYA;&QY+"!)('-U9V=E<W0@=&AA="!Y;W4@9&]N)W0@9V5T(&AU;F<@
M=7 @;VX@4T9?3D]424997U)%041?4D%77T1!5$$-"FYO<B!(5%1005!)("TM
M('EO=2=R92!R96%L;'D@;F]T(")L;W-I;F<B(&%N>71H:6YG(&EM<&]R=&%N
M="!O=&AE<B!T:&%N(&$-"F)I9R!H86ER8F%L;"!M97-S+@T*#0I!<R!F;W(@
M>6]U<B!S=&%T96UE;G0@:6X@(S(@86)O=70@24E3-B!U<VEN9R!U;F1O8W5M
M96YT960@2%144"!!4$D@=&\-"G!R;V-E<W,@=&AE(')A=R!D871A("TM($D@
M86T@;F]T(&$@;&%W>65R(&YO<B!A;2!)(&%U=&AO<FET871I=F4@;VX@=&AE
M#0IS=6)J96-T+"!B=70@22!C86X@=&5L;"!Y;W4@=&AA=#H-"C$N(%1H92!)
M25,@86YD($A45% N4UE3('1E86US('-P96YT(&$@;&]T(&]F('1I;64@=VET
M:"!T:&4@;&%W>65R<RP@=VAO#0IG<FEL;&5D('5S(&]V97(@86QL(&]F('1H
M:7,-"C(N($QE9V%L;'DL($E)4S8@:7,@8V]N<VED97)E9"!A('!A<G0@;V8@
M5VEN9&]W<R!397)V97(@,C P,R!/4SL@=&AU<R!T:&ES#0II<R!M97)E;'D@
M82!P<FEV871E($%022!B971W965N('1W;R!/4R!C;VUP;VYE;G1S("TM('=H
M:6-H(&ES('!E<F9E8W1L>0T*86-C97!T86)L92!B>2!T:&4@8V]N<V5N="!D
M96-R964N#0H-"BTM( T*+R]$879I9 T*24E3#0I4:&ES('!O<W1I;F<@:7,@
M<')O=FED960@(D%3($E3(B!W:71H(&YO('=A<G)A;G1I97,L(&%N9"!C;VYF
M97)S(&YO(')I9VAT<RX-"B\O#0HB2V]R;NEL(%#A;"(@/&%N;VYY;6]U<T!D
M:7-C=7-S:6]N<RYM:6-R;W-O9G0N8V]M/B!W<F]T92!I;B!M97-S86=E#0IN
M97=S.D]+9W=I4B4R,U5%2$$N,S Q,D!T:S)M<V9T;F=P,3,N<&AX+F=B;"XN
M+@T*2&DL#0H-"DDG=F4@9F]U;F0@=&AE<V4@87)T:6-L97,Z#0IH='1P.B\O
M<W5P<&]R="YM:6-R;W-O9G0N8V]M+V1E9F%U;'0N87-P>#]S8VED/6MB.V5N
M+75S.W$S,3$X-3(-"FAT=' Z+R]S=7!P;W)T+FUI8W)O<V]F="YC;VTO9&5F
M875L="YA<W!X/W-C:60]:V([96XM=7,[<3,R-S8Q,0T*#0I&:7)S="!O9B!A
M;&P@22=V92!G;W0@82!Q=65S=&EO;BX@4D5!1%]205=?1$%402!C86X@8F4@
M=7-E9"!T;R!M;V1I9GD@=&AE#0IR97%U97-T(&)O9'D@;F]T(&]N;'D@=&AE
M(&AE861E<G,N(%=H>2!I<R!I="!G;VYE/R!)9B!Y;W4@9&]N)W0@=V%N="!T
M;PT*;6]D:69Y(&ET<R!B96AA=FEO<B!Y;W4@<VAO=6QD(&%D9"!A(&YE=R!N
M;W1I9FEC871I;VX@='EP92 H:6YP=70@86YD(&]U='!U= T*87,@=V5L;"D@
M;VYL>2!F;W(@;6]D:69Y:6YG('1H92!E;G1I='D@8F]D>2X-"@T*0G5T(&UY
M(&UA:6X@<75E<W1I;VX@:7,@=&AA="!T:&ES(&%R=&EC;&4@<V%Y<R!T:&%T
M($E)4R V(&]P97)A=&5S('%U:71E#0ID:69F97)E;G0@:6X@24E3(#4@;6]D
M92X-"@T*22!S96-T:6]N(")34TP@:6X@24E3(#8N,"(@22=V92!R96%D('1H
M870@:6X@24E3(#4@;6]D92!)25,@-B!H;W-T<R!34TP@86YD#0IF:6QT97)S
M(&-A;B!U<V4@4T9?3D]424997U)%041?4D%77T1!5$$N(%1H:7,@8V%N(&UE
M86X@;VYE(&]F('1H92!T=V\@=&EN9W,Z#0HQ+B!)25,@-B!I<R!N;W0@=7-I
M;F<@2%144"!!4$D@870@86QL+@T*26X@=&AI<R!C87-E(&$@;&]T(&]F($A4
M5% @05!)(&)A<V5D('1H:6YG<R!C86X@8F4@8G)O:V5N+"!I;F-L=61I;F<@
M2%144 T*05!)(&)A<V5D(%=I;F1O=W,@<WES=&5M('-E<G9I8V5S(&%N9"!3
M44P@4V5R=F5R(%EU:V]N)W,@=V5B('-E<G9I8V5S+B!)9@T*:70G<R!T:&4@
M=')U=&@@:7,@82!V97)Y('-T<F%N9V4@=&AI;F<N#0H-"C(N($E)4R V(&ES
M('5S:6YG('5N9&]C=6UE;G1E9"!(5%10($%022!C86QL<R!T:&%T(&UA:V4@
M:70@<&]S<VEB;&4@=&\-"G!R;V-E<W,@=&AE(')A=R!D871A+@T*26X@=&AI
M<R!C87-E('EO=2!S:&]U;&0@9&]C=6UE;G0@=&AE<V4@05!)<R!A<R!T:&5Y
M(&-O=6QD(&)E('5S960@8GD@;W1H97)S+@T*#0IH='1P87!I+F1L;"!E>'!O
M<G1S('-O;64@=6YD;V-U;65N=&5D(&9U;F-T:6]N<R H=VET:&]U="!H96%D
M97(-"F1E8VQA<F%T:6]N<RD@=&AA="!A<F4@=7-E9"!O;FQY(&)Y($E)4RX@
M0G5T(&%S($A45% @05!)(&ES(&%N(&]P97)A=&EN9PT*<WES=&5M('-E<G9I
M8V4@86YD(&YO="!P87)T(&]F($E)4R!)('1H:6YK('EO=2!S:&]U;&0@9&]C
M=6UE;G0@86QL('1H90T*9G5N8W1I;VYA;&ET>2!O9B!(5%10($%022X-"@T*
84VEN8V5R96QY+ T*2V]R;NEL#0H-"@T*
`
end

Re: Windows HTTP API

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

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

Re: Windows HTTP API

[Bill Stoddard <bi...@wstoddard.com>]

William A. Rowe, Jr. wrote:

> At 11:47 AM 6/21/2004, Bill Stoddard wrote:
> 
>>William A. Rowe, Jr. wrote:
>>
>>
>>>Thanks for the interesting references and citations.
>>>Apache HTTP server works at a lower level, below the layer exposed
>>>by this http.dll API.  To actually use this interface would require a few
>>>things;
>>>1a) Either support the http channel with the apr_socket_foo() API (this
>>>    is not a great option - because the interface is too high level and
>>>    cannot be polled, etc)
>>>1b) or Implement an alternative core filter schema which works at the
>>>    http.dll API layer
>>
>>1c) Use the apr_iol patch posted to the mailing list long ago. Reimplimenting core_filter is not practically feasible (unless you have -lots- of time to waste maintaining and debugging a new core_filter).
> 
> 
> 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. 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.

Bill

Re: Windows HTTP API

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

At 11:47 AM 6/21/2004, Bill Stoddard wrote:
>William A. Rowe, Jr. wrote:
>
>>Thanks for the interesting references and citations.
>>Apache HTTP server works at a lower level, below the layer exposed
>>by this http.dll API.  To actually use this interface would require a few
>>things;
>>1a) Either support the http channel with the apr_socket_foo() API (this
>>     is not a great option - because the interface is too high level and
>>     cannot be polled, etc)
>>1b) or Implement an alternative core filter schema which works at the
>>     http.dll API layer
>
>1c) Use the apr_iol patch posted to the mailing list long ago. Reimplimenting core_filter is not practically feasible (unless you have -lots- of time to waste maintaining and debugging a new core_filter).

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?

If you wanted to keep it very clean, you could even replace our http header 
filters, since they are preprocessed under this http.dll API.

It seems overloading apr I/O is a long way around a trivial (logic) problem, 
didn't we already try and scuttle that very same sort of effort around our
overloaded memory allocation strategy?  Our conclusion was that the
overloaded memory providers were too slow, and I'm afraid for this case
that overloading in apr would create similar bottlenecks.

Bill

Re: Windows HTTP API

[Bill Stoddard <bi...@wstoddard.com>]

William A. Rowe, Jr. wrote:

> Thanks for the interesting references and citations.
> 
> Apache HTTP server works at a lower level, below the layer exposed
> by this http.dll API.  To actually use this interface would require a few
> things;
> 
> 1a) Either support the http channel with the apr_socket_foo() API (this
>      is not a great option - because the interface is too high level and
>      cannot be polled, etc)
> 
> 1b) or Implement an alternative core filter schema which works at the
>      http.dll API layer

1c) Use the apr_iol patch posted to the mailing list long ago. Reimplimenting core_filter is not practically 
feasible (unless you have -lots- of time to waste maintaining and debugging a new core_filter).


Bill

Re: Windows HTTP API

[Jeff White <jl...@earthlink.net>]

From: "William A. Rowe, Jr."

> Thanks for the interesting references and citations.

Yes but for anyone with the equipment
to test this stuff, the real interesting stuff
is just beginning in the next few months 
or years.

Being a retired old man without equipment,
(but still doing odd jobs) others will need to 
do the testing.  :)

> Apache HTTP server works at a lower level,
> below the layer exposed by this http.dll API.

Remember this:

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. :)

Some say as goes Windows XP SP2 goes
Windows...

So the question:

If on Windows XP SP2 one keeps the HTTP.SYS
and Firewall on (controlling all ports) for safety,
even on a firewalled network (remember that
just plugged in on the network "sick" laptop is 
behind the network firewall already), how does 
any Apache APR product get "access" to the 
Windows ports?

May be there is no ASF helpful Windows device 
in Windows XP SP2 or  even a "problem" but  
always test.

> To actually use this interface would require a few
> things;

HTTP.SYS is for fast kernel static HTML
output (97% of the HTTP actions) and new
Windows port sharing...

This is why IIS 6 uses HTTP.SYS first, either
quickly respond via HTTP.SYS or send it on to 
IIS or whatever...

>  apr_socket_foo() API

Yes most likely an APR thing, because one
does not need Apache HTTPD in order to
use these many new (may be required)
Windows APIs with APR products.

> So it's an interesting thought experiment to me.

And to others.

> 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.

<quote>

The HTTP application programming interface 
(API) enables applications to communicate 
over HTTP without using Microsoft Internet 
Information Server (IIS). Applications can 
register to receive HTTP requests for particular 
URLs, receive HTTP requests, and send HTTP 
responses. The HTTP API includes SSL support 
so applications can exchange data over secure 
HTTP connections without depending on IIS. 
It is also designed to work with I/O completion ports.

</quote>

Play with these new Windows XP SP2 devices, 
test 'em and see...  :)

Jeff

Re: Windows HTTP API

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Thanks for the interesting references and citations.

Apache HTTP server works at a lower level, below the layer exposed
by this http.dll API.  To actually use this interface would require a few
things;

1a) Either support the http channel with the apr_socket_foo() API (this
     is not a great option - because the interface is too high level and
     cannot be polled, etc)

1b) or Implement an alternative core filter schema which works at the
     http.dll API layer

2) Create a separate winhttp MPM 

  2.1) When initializing vhosts in post-config, map out the vhosts registered
        in httpd.conf and register them all with http.dll

  2.2) Instead of creating a pool of socket connections, create a pool
        of http.dll handlers

  2.3) Serve requests by initializing core input and output filters at the
        connection level to the handlers identified in either 1a or 1b above.

  2.4) If ssl support is desired, this code would look more like a winsock 
        SSL connection (see mod_netware_ssl), mod_ssl couldn't be used.

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.

This might be good discussion for the module development list, if anyone
is looking for how-to pointers, since in Apache 2.0 the MPM is just another
module (well, ok, a very sophisticated and key module, but a module
none-the-less.)  Nothing I described above is terribly difficult.

Bill



At 05:46 PM 6/20/2004, Kornél Pál wrote:
>> To successfully allow applications to
>> use the same port on different IP
>> addresses, you must use a new utility,
>> Httpcfg.exe.
>
>I don't agree with MUST as it uses HTTP API and it's source code is
>available as well.
>See http://msdn.microsoft.com/library/en-us/http/http/httpcfg_exe.asp
>
>> So I guess the real question is has one
>> tried Apache and IIS with Windows Server
>> 2003 or Windows XP SP2 via HTTP.SYS?
>
>Windows XP SP2 includes HTTP API however IIS 5.1 doesn't use it (uses
>Winsock) so this option doesn't exist, but on Windows Server 2003 with IIS
>6.0 it's a real opportunity.
>
>Sincerely,
>Kornél

Re: Windows HTTP API

[Jeff White <jl...@earthlink.net>]

From: "Kornél Pál"

> > I do not understand any of the above,
> > please explain...
>
> This means that this newsgroup is about
> development and is subjected mainly
> to developers and not administrators.

My post was for developers.

And I am well aware that many admins
read this list too.

But when I have a "mainly" admin post,
like Windows Scripting for example, I
use the Apache users list.

Unless I'm trying to convert Wrowe!  :)

> Thus I think if we provide some information
> we have to provide it to be subjected to
> developers and not administrators as well.

Sometimes they are both!

But it was a developer post about
a config tool.

Most developers use config tools also.

> If you say a developer "you must use a new utility,
> Httpcfg.exe"

I did not say anything.

I quoted snips, just  "parts" from an article,
so that other "developers" will be a ware
of this tool and how to adjust port usage
with this config tool called HTTPcgf.exe.

Hopefully they read the full article.

> he will think that this is the only way

If the "developer" only goes by "snips"
of an article, that is the developer's
"problem".

> and will not think about that this is for
> administrators,

Hopefully every developer reads "all" of
the link and understands the first rule of
writing - who is the author's target.

But developers, should not be bothered
because it was written for "admins".

Developers also read "admin" articles.  :)

>but he can use HTTP API.
>

So... For programs the developer
did not write or have source for?

Anway most developers I know will
quickly use HTTPcfg.exe to get that
process working as fast as possible
with the HTTP.SYS device ( and then
may be proceed to improving it).

> But this is my own opinion.:)

Okay.

> I don't want to discuss about things like this.:)
>

But you took time to make a point
out of it. :)

But it's okay, I believe it's a language
thing.  So it's over....  :)

Jeff

Re: Windows HTTP API

[Korn�l P�l <ko...@hotmail.com>]

> I do not understand any of the above,
> please explain...

This means that this newsgroup is about development and is subjected mainly
to developers and not administrators.
Thus I think if we provide some information we have to provide it to be
subjected to developers and not administrators as well.
If you say a developer "you must use a new utility, Httpcfg.exe" he will
think that this is the only way and will not think about that this is for
administrators, but he can use HTTP API.

But this is my own opinion.:)
I don't want to discuss about things like this.:)

Sincerely,
Kornel

Re: Windows HTTP API

[Jeff White <jl...@earthlink.net>]

From: "Kornél Pál"

> > I believe, in this "one" article (for 98
> > percent of the non coding admins) the
> > word "must" is correct for the new way
> > to control Windows ports.
> >
> > This article does not "mean" for "everyone"
> > this is the only way.
> >
> > Always ask who is this article written for?
> >
> > Then add your own know how  in order
> > to use the article information or not.

>
> This newsgroup is for developers
> so we have to tell the real truth:),
> as we know that altough there isn't an
> exe file to do something we are able to
> produce it.:)
>

I do not understand any of the above,
please explain...

Jeff

Re: Windows HTTP API

[Korn�l P�l <ko...@hotmail.com>]

> I believe, in this "one" article (for 98
> percent of the non coding admins) the
> word "must" is correct for the new way
> to control Windows ports.
>
> This article does not "mean" for "everyone"
> this is the only way.
>
> Always ask who is this article written for?
>
> Then add your own know how  in order
> to use the article information or not.

This newsgroup is for developers so we have to tell the real truth:), as we
know that altough there isn't an exe file to do something we are able to
produce it.:)

Re: Windows HTTP API

[Jeff White <jl...@earthlink.net>]

From: "Kornél Pál"

> > To successfully allow applications to
> > use the same port on different IP
> > addresses, you must use a new utility,
> > Httpcfg.exe.
>

> I don't agree with MUST

I believe, in this "one" article (for 98
percent of the non coding admins) the
word "must" is correct for the new way
to control Windows ports.

This article does not "mean" for "everyone"
this is the only way.

Always ask who is this article written for?

Then add your own know how  in order
to use the article information or not.

> as it uses
> HTTP API and it's source code is
> available as well.
> See
http://msdn.microsoft.com/library/en-us/http/http/httpcfg_exe.asp
>

Doc words are "a pain" but one
"may need" HTTPcfg.exe....

For those current "processes" that
do not know about this HTTP device,
(and non coders), in order to may be
work with HTTP.SYS.

This doesn't mean it will always work,
that is why "some" may need to rewrite
their code.  :)

> > So I guess the real question is has one
> > tried Apache and IIS with Windows Server
> > 2003 or Windows XP SP2 via HTTP.SYS?
>

> Windows XP SP2 includes HTTP API
> however IIS 5.1 doesn't use it (uses
> Winsock) so this option doesn't exist,

Not in the same way as

> but on Windows Server 2003 with IIS
> 6.0 it's a real opportunity.

But Apache and IIS 5.1 "do not talk together"
but "possibly may share" together a device on
the non server OS of Windows XP SP2 RC2.

Remember when one "works" with Apache
and Microsoft docs, one "must" _always_
"read between the lines and work differently
(with the docs)" in order to do stuff in a
different way.  Always take each doc for it's
"slant" on what it is talking about. There may
be other articles that "suggest" other ways.   :)

Jeff

Re: Windows HTTP API

[Jeff White <jl...@earthlink.net>]

From: "Kornél Pál"

> > To successfully allow applications to
> > use the same port on different IP
> > addresses, you must use a new utility,
> > Httpcfg.exe.
>

> I don't agree with MUST

I believe, in this "one" article (for 98
percent of the non coding admins) the
word "must" is correct for the new way
to control Windows ports.

This article does not "mean" for "everyone"
this is the only way.

Always ask who is this article written for?

Then add your own know how  in order
to use the article information or not.

> as it uses
> HTTP API and it's source code is
> available as well.
> See
http://msdn.microsoft.com/library/en-us/http/http/httpcfg_exe.asp
>

Doc words are "a pain" but one
"may need" HTTPcfg.exe....

For those current "processes" that
do not know about this HTTP device,
(and non coders), in order to may be
work with HTTP.SYS.

This doesn't mean it will always work,
that is why "some" may need to rewrite
their code.  :)

> > So I guess the real question is has one
> > tried Apache and IIS with Windows Server
> > 2003 or Windows XP SP2 via HTTP.SYS?
>

> Windows XP SP2 includes HTTP API
> however IIS 5.1 doesn't use it (uses
> Winsock) so this option doesn't exist,

Not in the same way as

> but on Windows Server 2003 with IIS
> 6.0 it's a real opportunity.

But Apache and IIS 5.1 "do not talk together"
but "possibly may share" together a device on
the non server OS of Windows XP SP2 RC2.

Remember when one "works" with Apache
and Microsoft docs, one "must" _always_
"read between the lines and work differently
(with the docs)" in order to do stuff in a
different way.  Always take each doc for it's
"slant" on what it is talking about. There may
be other articles that "suggest" other ways.   :)

Jeff

Re: Windows HTTP API

[Korn�l P�l <ko...@hotmail.com>]

> To successfully allow applications to
> use the same port on different IP
> addresses, you must use a new utility,
> Httpcfg.exe.

I don't agree with MUST as it uses HTTP API and it's source code is
available as well.
See http://msdn.microsoft.com/library/en-us/http/http/httpcfg_exe.asp

> So I guess the real question is has one
> tried Apache and IIS with Windows Server
> 2003 or Windows XP SP2 via HTTP.SYS?

Windows XP SP2 includes HTTP API however IIS 5.1 doesn't use it (uses
Winsock) so this option doesn't exist, but on Windows Server 2003 with IIS
6.0 it's a real opportunity.

Sincerely,
Korn�l

Re: Windows HTTP API

[Jeff White <jl...@earthlink.net>]

From: "Kornél Pál"

>
> Microsoft describes http.sys as the
> kernel mode cache of IIS 6, however it's
> kernel mode HTTP listener with cache for
> any application.
>

<quote>

The HTTP application programming interface
(API) enables applications to communicate
over HTTP without using Microsoft Internet
Information Server (IIS).

</quote>

Anyway, at first, there will just be "a few"
hundreds of million or so, of these default
on HTTP.SYS devices, active on the Internet.

Because it seems HTTP.SYS (a HTTP listener
and router and responder with cache, SSL, and
etc.) will be a part of all Windows systems. Yes
HTTP.SYS is being back ported to Windows XP
SP2 and this and other Windows XP SP2 changes
may be added to the higher up Windows systems.

> Using http.sys Apache HTTPD could be
> used with IIS 6 on Windows sharing the
> same port and IP address. I think this is
> a good thing if you want to host more web
> sites using different server software on the
> same server.
>

Yes since HTTP.SYS (default on) will allow
other processes to share the same port (if
using the HTTP.SYS APIs or the HTTP
config tool). Or perhaps, via the newer .NET
Framework HttpListener class (works with
HTTP.SYS), is a simple Web server (that
can self-host ) or work with others.

Grandpa and Grandma can turn their kiddies
HTTP pictures (site) off and on. Or business
users can turn off and on, their many simple
HTTP get and send actions (web services too).

And if the URI is not valid or there is nothing
registered (with HTTP.SYS) and the port is
open, then HTTP.SYS returns a HTTP error
message.

>
> I think you should consider implementing
> HTTP API in Apache HTTPD as it has
> a lot of possibilities.
>
> More information about HTTP API
> is available in Platform SDK:
>
http://msdn.microsoft.com/library/en-us/http/http/http_api_start_page.asp
>
> Sincerely,
> Kornél
>

I added Apache APR because APR is
where ASF's HTTPD and APR users,
that access Windows ports (for one
thing), will use or not use these new
Windows system wide changes.

The Windows HTTP.SYS device
(Windows XP SP2 and higher) and the
new Windows Installer (Windows 2000
and up) and of course, the Windows
Firewall (Windows XP SP2 and higher).

And these above objects do not include
the many major changes to the system
shell HTTP reader, commonly called
Internet Explorer.

All these new Windows system objects
will be "default on" for the user (and most
users will / should keep them on). So all
other programs will need to be "aware of
and work with" these new Windows system
wide objects.

Release Notes for Microsoft Windows XP Service Pack 2
Release Candidate 2
Updated: June 14, 2004
http://www.microsoft.com/technet/prodtechnol/winxppro/deploy/relsprc2.mspx

Windows XP Service Pack 2 Release Candidate 2 Preview
http://www.microsoft.com/technet/prodtechnol/winxppro/sp2preview.mspx

<quote>

To successfully allow applications to
use the same port on different IP
addresses, you must use a new utility,
Httpcfg.exe.

</quote>

Perhaps this really means:

<quote>

The HTTP API allows multiple applications
to co-exist on a system, sharing the same TCP
port (for example, port 80 for HTTP or port 443
for HTTPS) and serving different parts of the
URL namespace.

<quote>

HTTP.SYS can route by any:
URI or parts of the URI. So
continuing on:

<quote>

Httpcfg.exe is located on
the Windows Server 2003 CD in the
Support\Tools directory as part of the
Support.cab file.

Snip

To configure HTTP.sys, you must use
Httpcfg.exe.

Snip

In IIS 6.0, HTTP.sys is the TCP listener and
HTTP.sys does not use the Winsock API.
Sockets are not a configurable property.
HTTP.sys uses an IP inclusion list. By default,
this list is blank and IIS listens on all IP addresses.

You can specify the IP addresses IIS will listen
on by adding them to the IP inclusion list.

</quote>

IIS 6.0: Setting Metabase Property
DisableSocketPooling Has No Effect
http://support.microsoft.com/default.aspx?scid=kb;EN-US;813368

Also the people who bring you HTTP.SYS
and the WINHTTP.DLL now have a blog.

<quote>

This is a collaborative Weblog from
the Web Transports Team in Windows
Networking. As a team we work on the
http stacks in Windows; http.sys the kernel
part of the IIS 6.0 Web Server (part of
Windows Server 2003) and its own
developer API, wininet.dll which is the
client side HTTP stack at the heart of
Internet Explorer, and winhttp.dll which
is the client side HTTP stack favored by
server applications relying on performance
and reliability.

</quote>

The Web Transports team
http://blogs.msdn.com/webtransports/

So I guess the real question is has one
tried Apache and IIS with Windows Server
2003 or Windows XP SP2 via HTTP.SYS?

Jeff

Re: Windows HTTP API

[Jeff White <jl...@earthlink.net>]

From: "Kornél Pál"

>
> Microsoft describes http.sys as the
> kernel mode cache of IIS 6, however it's
> kernel mode HTTP listener with cache for
> any application.
>

<quote>

The HTTP application programming interface
(API) enables applications to communicate
over HTTP without using Microsoft Internet
Information Server (IIS).

</quote>

Anyway, at first, there will just be "a few"
hundreds of million or so, of these default
on HTTP.SYS devices, active on the Internet.

Because it seems HTTP.SYS (a HTTP listener
and router and responder with cache, SSL, and
etc.) will be a part of all Windows systems. Yes
HTTP.SYS is being back ported to Windows XP
SP2 and this and other Windows XP SP2 changes
may be added to the higher up Windows systems.

> Using http.sys Apache HTTPD could be
> used with IIS 6 on Windows sharing the
> same port and IP address. I think this is
> a good thing if you want to host more web
> sites using different server software on the
> same server.
>

Yes since HTTP.SYS (default on) will allow
other processes to share the same port (if
using the HTTP.SYS APIs or the HTTP
config tool). Or perhaps, via the newer .NET
Framework HttpListener class (works with
HTTP.SYS), is a simple Web server (that
can self-host ) or work with others.

Grandpa and Grandma can turn their kiddies
HTTP pictures (site) off and on. Or business
users can turn off and on, their many simple
HTTP get and send actions (web services too).

And if the URI is not valid or there is nothing
registered (with HTTP.SYS) and the port is
open, then HTTP.SYS returns a HTTP error
message.

>
> I think you should consider implementing
> HTTP API in Apache HTTPD as it has
> a lot of possibilities.
>
> More information about HTTP API
> is available in Platform SDK:
>
http://msdn.microsoft.com/library/en-us/http/http/http_api_start_page.asp
>
> Sincerely,
> Kornél
>

I added Apache APR because APR is
where ASF's HTTPD and APR users,
that access Windows ports (for one
thing), will use or not use these new
Windows system wide changes.

The Windows HTTP.SYS device
(Windows XP SP2 and higher) and the
new Windows Installer (Windows 2000
and up) and of course, the Windows
Firewall (Windows XP SP2 and higher).

And these above objects do not include
the many major changes to the system
shell HTTP reader, commonly called
Internet Explorer.

All these new Windows system objects
will be "default on" for the user (and most
users will / should keep them on). So all
other programs will need to be "aware of
and work with" these new Windows system
wide objects.

Release Notes for Microsoft Windows XP Service Pack 2
Release Candidate 2
Updated: June 14, 2004
http://www.microsoft.com/technet/prodtechnol/winxppro/deploy/relsprc2.mspx

Windows XP Service Pack 2 Release Candidate 2 Preview
http://www.microsoft.com/technet/prodtechnol/winxppro/sp2preview.mspx

<quote>

To successfully allow applications to
use the same port on different IP
addresses, you must use a new utility,
Httpcfg.exe.

</quote>

Perhaps this really means:

<quote>

The HTTP API allows multiple applications
to co-exist on a system, sharing the same TCP
port (for example, port 80 for HTTP or port 443
for HTTPS) and serving different parts of the
URL namespace.

<quote>

HTTP.SYS can route by any:
URI or parts of the URI. So
continuing on:

<quote>

Httpcfg.exe is located on
the Windows Server 2003 CD in the
Support\Tools directory as part of the
Support.cab file.

Snip

To configure HTTP.sys, you must use
Httpcfg.exe.

Snip

In IIS 6.0, HTTP.sys is the TCP listener and
HTTP.sys does not use the Winsock API.
Sockets are not a configurable property.
HTTP.sys uses an IP inclusion list. By default,
this list is blank and IIS listens on all IP addresses.

You can specify the IP addresses IIS will listen
on by adding them to the IP inclusion list.

</quote>

IIS 6.0: Setting Metabase Property
DisableSocketPooling Has No Effect
http://support.microsoft.com/default.aspx?scid=kb;EN-US;813368

Also the people who bring you HTTP.SYS
and the WINHTTP.DLL now have a blog.

<quote>

This is a collaborative Weblog from
the Web Transports Team in Windows
Networking. As a team we work on the
http stacks in Windows; http.sys the kernel
part of the IIS 6.0 Web Server (part of
Windows Server 2003) and its own
developer API, wininet.dll which is the
client side HTTP stack at the heart of
Internet Explorer, and winhttp.dll which
is the client side HTTP stack favored by
server applications relying on performance
and reliability.

</quote>

The Web Transports team
http://blogs.msdn.com/webtransports/

So I guess the real question is has one
tried Apache and IIS with Windows Server
2003 or Windows XP SP2 via HTTP.SYS?

Jeff