How to get my IHttpNegotiate implementation called by IWebBrowser? - c++

Question

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!

Answer 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