How to get my IHttpNegotiate implementation called

2019-06-05 19:50发布

问题:

I use cwebpage_src code and I need to update some HTTP request headers while clicking on links. As I understand it can be done with self implementation of IHttpNegotiate->BeginTransaction. But how to get my IHttpNegotiate implementation called??

Thanks!

回答1:

Although I have no experience of writing one, I believe that you need to write an asynchronous pluggable protocol, as recommended in this thread.

Details of how and why to do this are scattered around the web in various places, but the best exposition that I've read is in this post by Igor Tandetnik (abridged here for brevity):

There are several technology layers that support the download and navigation in Internet Explorer and WebBrowser control. At the top, there is WebBrowser itself and MSHTML object that provides HTML parsing and rendering. The client uses such interfaces as IWebBrowser2 and IHTMLDocument2 to communicate with these high-level objects.

WebBrowser and MSHTML use URL Monikers library to perform actual downloads. URLMon exposes its services via IMoniker and IBinding interfaces, and the client (say MSHTML) implements IBindStatusCallback and a number of associated interfaces, e.g. IHttpNegotiate or IAuthenticate.

Next down is an Asynchronous Pluggable Protocol handler. An APP encapsulates the details of a particular protocol, such as http, file or res.

...

Most of the time, an application hosting a WebBrowser control (or a BHO running inside IE) uses high-level services provided by WebBrowser and MSHTML objects. However, sometimes these services are insufficient, and a lower-level hook is required.

...

It would be nice to be able to hook into the communication sequence between WebBrowser/MSHTML and URL Monikers. Unfortunately, there does not seem to be any way to do that - at least, none that I know of. So, we look at the next level - a communication between a URL moniker and an APP.

...

Now, it is rarely necessary to implement a full-blown APP from scratch - after all, how often do new protocols actually get defined? But for our purposes, it is useful to implement a so-called passthrough APP (pAPP). A pApp is an object that implements both sides of URL moniker-to-APP communication, that is, it implements both IInternetProtocol and IInternetProtocolSink / IInternetBindInfo. We register it as a temporary handler for a standard protocol, such as HTTP. Now whenever an HTTP request needs to be sent, URL moniker will create an instance of our pAPP and ask it to do the job. The pAPP then creates an instance of a standard APP for the protocol in question (I call it a target APP, or tAPP, but be aware that I've invented the terminology myself, it's not widely accepted, suggestions for a better naming convention are welcome) and acts as its client. At this point, our pAPP becomes a proverbial man-in-the-middle. In the simplest case, any method call made by URL Moniker on pAPP is forwarded to tAPP, and any method call made by tAPP on pAPP is forwarded back to URL Moniker. The pAPP gets to observe and, if desired, modify every bit of information relevant to this request passing back and forth between the moniker and the tAPP.

Igor has a couple of sample projects that should help in writing your own pAPP:

  • PassthruApp.zip
  • PassthruAppBeta.zip