A naive question about Http.Sys

Hello,

I have a question about some Http.Sys functionality. I have written
many ISAPI extensions and filters but have yet to do much using the
Http.Sys API. I'm writing an application right now that needs to do
some post-processing on websites (replacing HTML tags with other tags,
etc) and am wondering if using an ISAPI filter is still the best
option for this particular scenario.

My understanding is that you can have port-sharing with Http.Sys,
which (per my small understanding) means I could let IIS handle
requests for some web-sites while I handle requests for others (am I
right?). If IIS is already hosting the site internally, and if I set
that site to some other port number (other than 80), in theory I could
have my Http.Sys application make a "sub-request" to the internal IIS
site and work on the response it gets back from IIS.

I have no problem coding in ISAPI, but Microsoft seems to be shifting
themselves AWAY from writing ISAPI filters and - as everyone knows -
they can be buggy, tough bastards to write. So I'm looking for easier,
more well-supported solutions that can scale well (both in terms of
server load and coding time).

I guess my questions are:

1. Would this scale well? I'm not sure what I think about this idea,
2. Would this even work? I'm not sure what I think about that either,
3. Would this be secure?

Thoughts?

Re: A naive question about Http.Sys

On Dec 5, 12:06 pm, kwen...@yahoo.com wrote:
> Hello,
>
> I have a question about some Http.Sys functionality. I have written
> many ISAPI extensions and filters but have yet to do much using the
> Http.Sys API. I'm writing an application right now that needs to do
> some post-processing on websites (replacing HTML tags with other tags,
> etc) and am wondering if using an ISAPI filter is still the best
> option for this particular scenario.
>
> My understanding is that you can have port-sharing with Http.Sys,
> which (per my small understanding) means I could let IIS handle
> requests for some web-sites while I handle requests for others (am I
> right?). If IIS is already hosting the site internally, and if I set
> that site to some other port number (other than 80), in theory I could
> have my Http.Sys application make a "sub-request" to the internal IIS
> site and work on the response it gets back from IIS.
>
> I have no problem coding in ISAPI, but Microsoft seems to be shifting
> themselves AWAY from writing ISAPI filters and - as everyone knows -
> they can be buggy, tough bastards to write. So I'm looking for easier,
> more well-supported solutions that can scale well (both in terms of
> server load and coding time).
>
> I guess my questions are:
>
> 1. Would this scale well? I'm not sure what I think about this idea,
> 2. Would this even work? I'm not sure what I think about that either,
> 3. Would this be secure?
>
> Thoughts?


From IIS7 onwards, I recommend writing a native or managed Module to
accomplish what you want. It is the supported approach, and it will be
far easier than anything you try to do with HTTP API directly. And of
course the native module will scale and be secure.

IIS7 itself already does what you want within its own native module,
for its kernel response cache purposes. You will have to duplicate
that work because response buffering is not generic enough to expose
(conflicts with Chunked Encoding); I'm just telling you it is easily
doable.

HTTP API applications are given non-overlapping URL namespaces to
handle, and it is not the way to go for what you want.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

Re: A naive question about Http.Sys

Thanks for your response. Unfortunately I do not have the luxury of
working in IIS 7, only IIS 6. So, I'm stuck with ISAPI filters
unfortunately. Thanks for your input.

On Dec 5, 2:53 pm, David Wang wrote:
> On Dec 5, 12:06 pm, kwen...@yahoo.com wrote:
>
>
>
>
>
> > Hello,
>
> > I have a question about some Http.Sys functionality. I have written
> > many ISAPI extensions and filters but have yet to do much using the
> > Http.Sys API. I'm writing an application right now that needs to do
> > some post-processing on websites (replacing HTML tags with other tags,
> > etc) and am wondering if using an ISAPI filter is still the best
> > option for this particular scenario.
>
> > My understanding is that you can have port-sharing with Http.Sys,
> > which (per my small understanding) means I could let IIS handle
> > requests for some web-sites while I handle requests for others (am I
> > right?). If IIS is already hosting the site internally, and if I set
> > that site to some other port number (other than 80), in theory I could
> > have my Http.Sys application make a "sub-request" to the internal IIS
> > site and work on the response it gets back from IIS.
>
> > I have no problem coding in ISAPI, but Microsoft seems to be shifting
> > themselves AWAY from writing ISAPI filters and - as everyone knows -
> > they can be buggy, tough bastards to write. So I'm looking for easier,
> > more well-supported solutions that can scale well (both in terms of
> > server load and coding time).
>
> > I guess my questions are:
>
> > 1. Would this scale well? I'm not sure what I think about this idea,
> > 2. Would this even work? I'm not sure what I think about that either,
> > 3. Would this be secure?
>
> > Thoughts?
>
> From IIS7 onwards, I recommend writing a native or managed Module to
> accomplish what you want. It is the supported approach, and it will be
> far easier than anything you try to do with HTTP API directly. And of
> course the native module will scale and be secure.
>
> IIS7 itself already does what you want within its own native module,
> for its kernel response cache purposes. You will have to duplicate
> that work because response buffering is not generic enough to expose
> (conflicts with Chunked Encoding); I'm just telling you it is easily
> doable.
>
> HTTP API applications are given non-overlapping URL namespaces to
> handle, and it is not the way to go for what you want.
>
> //Davidhttp://w3-4u.blogspot.comhttp://blogs.msdn.com/David. Wang
> //- Hide quoted text -
>
> - Show quoted text -

Re: A naive question about Http.Sys

And just for posterity's sake, the idea *did* work to a degree; I was
able to put one of my sites on port 81 and then replace it with a
HTTP.SYS app listening on port 80. I then did a sub-request for the
site on port 81 by my HTTP.SYS app and, save a couple bugs I
encountered that I'm pretty sure were my fault, it worked - I got the
page back.

I will take your recommendation, however, and just write this thing as
an ISAPI filter.



On Dec 5, 3:24 pm, kwen...@yahoo.com wrote:
> Thanks for your response. Unfortunately I do not have the luxury of
> working in IIS 7, only IIS 6. So, I'm stuck with ISAPI filters
> unfortunately. Thanks for your input.
>
> On Dec 5, 2:53 pm, David Wang wrote:
>
>
>
> > On Dec 5, 12:06 pm, kwen...@yahoo.com wrote:
>
> > > Hello,
>
> > > I have a question about some Http.Sys functionality. I have written
> > > many ISAPI extensions and filters but have yet to do much using the
> > > Http.Sys API. I'm writing an application right now that needs to do
> > > some post-processing on websites (replacing HTML tags with other tags,
> > > etc) and am wondering if using an ISAPI filter is still the best
> > > option for this particular scenario.
>
> > > My understanding is that you can have port-sharing with Http.Sys,
> > > which (per my small understanding) means I could let IIS handle
> > > requests for some web-sites while I handle requests for others (am I
> > > right?). If IIS is already hosting the site internally, and if I set
> > > that site to some other port number (other than 80), in theory I could
> > > have my Http.Sys application make a "sub-request" to the internal IIS
> > > site and work on the response it gets back from IIS.
>
> > > I have no problem coding in ISAPI, but Microsoft seems to be shifting
> > > themselves AWAY from writing ISAPI filters and - as everyone knows -
> > > they can be buggy, tough bastards to write. So I'm looking for easier,
> > > more well-supported solutions that can scale well (both in terms of
> > > server load and coding time).
>
> > > I guess my questions are:
>
> > > 1. Would this scale well? I'm not sure what I think about this idea,
> > > 2. Would this even work? I'm not sure what I think about that either,
> > > 3. Would this be secure?
>
> > > Thoughts?
>
> > From IIS7 onwards, I recommend writing a native or managed Module to
> > accomplish what you want. It is the supported approach, and it will be
> > far easier than anything you try to do with HTTP API directly. And of
> > course the native module will scale and be secure.
>
> > IIS7 itself already does what you want within its own native module,
> > for its kernel response cache purposes. You will have to duplicate
> > that work because response buffering is not generic enough to expose
> > (conflicts with Chunked Encoding); I'm just telling you it is easily
> > doable.
>
> > HTTP API applications are given non-overlapping URL namespaces to
> > handle, and it is not the way to go for what you want.
>
> > //Davidhttp://w3-4u.blogspot.comhttp://blogs.msdn.com/David. Wang
> > //- Hide quoted text -
>
> > - Show quoted text -- Hide quoted text -
>
> - Show quoted text -