Re: Passthrough APP help, please..

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

On Nov 7, 3:12 pm, "Igor Tandetnik" <itandet...@xxxxxxxx> wrote:
Nate <nmoinvaz...@xxxxxxxxx> wrote:
On Nov 7, 6:26 am, "Igor Tandetnik" <itandet...@xxxxxxxx> wrote:
"Nate" <nmoinvaz...@xxxxxxxxx> wrote in message
Yea my bad. I used the wrong term here. So in essence you create the
real APP with CoCreateInstance like so,

CoCreateInstance(&CLSID_HttpProtocol, NULL, CLCTX_INPROC_SERVER,
&IID_IInternetProtocol, (void**)&InternetProtocol);
Right?

Right.

How do you hook up the following interfaces, IInternetProtocolSink,
IWinInetInfo/IWinInetHttpInfo, IInternetThreadSwitch,
IInternetPriority.

What do you mean, hook up? I'm afraid I'm not familiar with the term.

What I mean is what is the order things are queried?

Why do you care?

Are IWinInetInfo/IWinInetHttpInfo, IInternetThreadSwitch, and
IInternetPriority all queried from IInternetProtocol?

Yes. IInternetThreadSwitch is never queried for though, in my
experience. It's not documented, and I don't know what it's supposed to
do.

From whom is IHttpNegotiate queried?

IHttpNegotiate is implemented by the sink, not by the protocol. You
query for IServiceProvider off IInternetProtocolSink pointer you get in
Start, then call QueryService(IID_IHttpNegotiate).

How is your CTestSink::BeginningTransaction being called?
How is that queried for or connected to the whole thing?

As far as I can tell CTestSink implements IHttpNegotiate, but how do
you tell
IInternetProtocol to use your IHttpNegotiate interface rather than its
own.


I monitor IInternetProtocol::QueryInterface and none of these
interfaces are queried for.. should they be?

IInternetProtocolSink is implemented by a sink object, not protocol
object. IInternetThreadSwitch doesn't appear to be used - I've only
implemented it for completeness. The other three are most certainly
queried for and called. IInternetPriority::SetPriority is usually
called even before IInternetProtocol::Start

Why implement your own IInternetPriority interface?

Because the client queries for it.

Why not just give
it the real APP's IInternetPriority interface?

That would violate COM rules. First, it is possible (though unlikely in
practice) that the client would query from this IInternetPriority
pointer back to some other interface the client thinks is implemented on
the same object - e.g. IInternetProtocol. Of course, the real APP
doesn't know anything about your object, so it's going to give out its
own IInternetProtocol, and bypass yours.

This also violates COM identity rule: querying from any interface of an
object for IUnknown should produce the same IUnknown pointer. The client
can use this rule to test whether two interface pointers in fact belong
to the same object. See also CComPtr::IsEqualObject.

Apart from all this theory, there's an important practical
consideration. UrlMon - your most likely client - itself violates COM
rules in many ways. In particular, it sometimes AddRef's through one
interface pointer but Releases through another (which is illegal in
COM). This doesn't create problems as long as all interfaces are
trivially implemented on the same object and share a common refcount.
But if you give out IInternetPriority from the real APP (which
implicitly AddRef's it), UrlMon may later Release through one of _your_
interfaces. Effectively, your object will get a Release without a
matching AddRef, and will be destroyed prematurely. Which of course
would most likely lead to a crash.

One possibility would be to aggregate the real APP into your APP (a
built-in HTTP handler supports aggregation). I tried it, but the
reference counting issues got so complicated that I gave up pretty
quickly. See if you want to go down this way - you might have more
patience that I do.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925


.

Relevant Pages

  • Re: Passthrough APP help, please..
    ... your own IInternetProtocol/Root interface that you've implemented. ... So my APP implements every interface I know of that a real APP may, ... it in turn queries the real APP for the same ... IInternetPriority all queried from IInternetProtocol? ...
    (microsoft.public.inetsdk.programming.webbrowser_ctl)
  • Re: Passthrough APP help, please..
    ... IInternetPriority all queried from IInternetProtocol? ... Why implement your own IInternetPriority interface? ... Because the client queries for it. ... Of course, the real APP ...
    (microsoft.public.inetsdk.programming.webbrowser_ctl)
  • Re: Passthrough APP help, please..
    ... your own IInternetProtocol/Root interface that you've implemented. ... Whenever any of your custom IInternetProtocol interface functions are ... So my APP implements every interface I know of that a real APP may, ... it in turn queries the real APP for the same ...
    (microsoft.public.inetsdk.programming.webbrowser_ctl)