PassThroughApp & BHOs -- shouldn't do that

[Don Schmitt]

I was just reviewing the PassThroughApp, so apologies if I'm missing
something.

But on first glance, it appears to me that all these BHO extensions that are
using PassThroughApp are not going to work when other extensions are trying
to use the same approach, because the last caller to RegisterNameSpace wins.
This includes, apparently, Google Gears
(http://code.google.com/p/gears/source/browse/trunk/gears/localserver/ie/http_handler_app.h?spec=svn3169&r=3169)

Shouldn't extension developers be relying on some other solution that can
play well with others?

[Don Schmitt]

Well, to avoid these problems, I have decided to go with a different approach
than the approach used by PassThruAPP.

The approach I've decided to use is to replace the Start & StartEx methods
in the IInernetProtocolRoot and IInternetProtocolEx v-tables with my own
implementations.

From there, you can replace the IInternetProtocolSink with your own
implementation before calling the original StartEx method.

Granted, it's not a documented / supported way to do things, but I don't
think that shipping extensions that won't work with any other extensions is a
better idea.

The implementation is actually much simpler than PassThruAPP, and it will
not conflict with other extension developers who are using the same approach
or even ones who use the PassThruAPP mechanism.

That's the theory anyhow...I haven't finished testing it yet.

Post by Don Schmitt
I was just reviewing the PassThroughApp, so apologies if I'm missing
something.
But on first glance, it appears to me that all these BHO extensions that are
using PassThroughApp are not going to work when other extensions are trying
to use the same approach, because the last caller to RegisterNameSpace wins.
This includes, apparently, Google Gears
(http://code.google.com/p/gears/source/browse/trunk/gears/localserver/ie/http_handler_app.h?spec=svn3169&r=3169)
Shouldn't extension developers be relying on some other solution that can
play well with others?

[Don Schmitt]

I am now using this approach instead of the PassThrough APP approach. Here
is a blog entry that has pseudo-code for that implementation:
http://www.blackfishsoftware.com/blog/don/passthroughapp_bho_toolbar_intercepting_requests_responses

Post by Don Schmitt
Well, to avoid these problems, I have decided to go with a different approach
than the approach used by PassThruAPP.
The approach I've decided to use is to replace the Start & StartEx methods
in the IInernetProtocolRoot and IInternetProtocolEx v-tables with my own
implementations.
From there, you can replace the IInternetProtocolSink with your own
implementation before calling the original StartEx method.
Granted, it's not a documented / supported way to do things, but I don't
think that shipping extensions that won't work with any other extensions is a
better idea.
The implementation is actually much simpler than PassThruAPP, and it will
not conflict with other extension developers who are using the same approach
or even ones who use the PassThruAPP mechanism.
That's the theory anyhow...I haven't finished testing it yet.

Post by Don Schmitt
I was just reviewing the PassThroughApp, so apologies if I'm missing
something.
But on first glance, it appears to me that all these BHO extensions that are
using PassThroughApp are not going to work when other extensions are trying
to use the same approach, because the last caller to RegisterNameSpace wins.
This includes, apparently, Google Gears
(http://code.google.com/p/gears/source/browse/trunk/gears/localserver/ie/http_handler_app.h?spec=svn3169&r=3169)
Shouldn't extension developers be relying on some other solution that can
play well with others?

[Neil.Young]

Hi Don,

there are some buzz words in your posting, which do attract me :) "A
common requirement for an IE extension (BHO or toolbar) is for it to be
able to manipulate any request that is made by the browser. Another
common requirement is for it to be able to view any response that the
browser receives."

Probably you have watched the discussion I had with Igor, concerning the
possibility to use the UrlMoniker technology to act as a local HTTP
proxy, without having to configure a proxy. I have to admit, I didn't
leave the discussion much more foxy, compared to how I entered it,
probably, because Igor is just dropping just one or two words :) That's
definitely not enough for newbies in ATL, COM, APP and stuff.

I'm good with C# and .net back and forth and do currently have all, what
I want to achieve with either UrlMonikers or APP, already coded as a
HTTP proxy. The proxy watches incoming HTTP for 401 and performs all the
required actions (as standardized by 3GPP), which are necessary to add
3GPP GBA AKA authentication to your browser. The advantage: A proxy
solution is highly portable (Firefox, IE, runs on Windows, Linux,
Windows Mobile and S60), but the drawback: It has to be configured. I
also know, that it shall be possible to code BHO in C#.

I'm looking for an installable plugin, which acts like a local proxy for
HTTP and HTTPS. Do you think, your approach could be the framework for
achieving this kind of functionality for IE6 to IE8++?

Kind regards

Post by Don Schmitt
I am now using this approach instead of the PassThrough APP approach. Here
http://www.blackfishsoftware.com/blog/don/passthroughapp_bho_toolbar_intercepting_requests_responses

Post by Don Schmitt
Well, to avoid these problems, I have decided to go with a different approach
than the approach used by PassThruAPP.
The approach I've decided to use is to replace the Start & StartEx methods
in the IInernetProtocolRoot and IInternetProtocolEx v-tables with my own
implementations.
From there, you can replace the IInternetProtocolSink with your own
implementation before calling the original StartEx method.
Granted, it's not a documented / supported way to do things, but I don't
think that shipping extensions that won't work with any other extensions is a
better idea.
The implementation is actually much simpler than PassThruAPP, and it will
not conflict with other extension developers who are using the same approach
or even ones who use the PassThruAPP mechanism.
That's the theory anyhow...I haven't finished testing it yet.

Post by Don Schmitt
I was just reviewing the PassThroughApp, so apologies if I'm missing
something.
But on first glance, it appears to me that all these BHO extensions that are
using PassThroughApp are not going to work when other extensions are trying
to use the same approach, because the last caller to RegisterNameSpace wins.
This includes, apparently, Google Gears
(http://code.google.com/p/gears/source/browse/trunk/gears/localserver/ie/http_handler_app.h?spec=svn3169&r=3169)
Shouldn't extension developers be relying on some other solution that can
play well with others?

[Neil.Young]

Post by Don Schmitt
I am now using this approach instead of the PassThrough APP approach. Here
http://www.blackfishsoftware.com/blog/don/passthroughapp_bho_toolbar_intercepting_requests_responses

Hi Don,

there are some buzz words in your blog, which do attract me :) "A common
requirement for an IE extension (BHO or toolbar) is for it to be able to
manipulate any request that is made by the browser. Another common
requirement is for it to be able to view any response that the browser
receives."

Probably you have watched the discussion I had with Igor, concerning the
possibility to use the UrlMoniker technology to act as a local HTTP
proxy, without having to configure a proxy. I have to admit, I didn't
leave the discussion much more foxy, compared to how I entered it,
probably, because Igor is just dropping just one or two words :) That's
definitely not enough for newbies in ATL, COM, APP and stuff.

I'm good with C# and .net back and forth and do currently have all, what
I want to achieve with either UrlMonikers or APP, already coded as a
HTTP proxy. The proxy watches incoming HTTP for 401 and performs all the
required actions (as standardized by 3GPP), which are necessary to add
3GPP GBA AKA authentication to your browser. The advantage: A proxy
solution is highly portable (Firefox, IE, runs on Windows, Linux,
Windows Mobile and S60), but the drawback: It has to be configured. I
also know, that it shall be possible to code BHO in C#.

I'm looking for an installable plugin, which acts like a local proxy for
HTTP and HTTPS. Do you think, your approach could be the framework for
achieving this kind of functionality for IE6 to IE8++?

Kind regards

[Neil.Young]

Sorry, double post was not by intention...