如何让 IWebBrowser 调用我的 IHttpNegotiate 实现？

发布于 2024-09-19 00:38:31 字数 258 浏览 11 评论 0原文

我使用 cwebpage_src 代码，我需要更新一些单击链接时的 HTTP 请求标头。据我了解，这可以通过 IHttpNegotiate->BeginTransaction 的自我实现来完成。但是如何调用我的 IHttpNegotiate 实现？

谢谢！

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

合约呢 2024-09-26 00:38:35

虽然我没有编写异步代码的经验，但我相信您需要编写一个异步可插入协议，如此线程。

有关如何以及为何执行此操作的详细信息分散在网络上的各个地方，但我读过的最好的说明位于这篇文章，作者：Igor Tandetnik（为简洁起见，此处省略）：

有几个技术层
支持下载和
Internet Explorer 中的导航和
Web 浏览器控件。在顶部，有
是WebBrowser本身和MSHTML对象
提供 HTML 解析和
渲染。客户端使用这样的
接口为 IWebBrowser2 和
与之通信的 IHTMLDocument2
这些高级对象。
WebBrowser 和 MSHTML 使用 URL 名字对象
库来执行实际下载。
URLMon 通过以下方式公开其服务
IMoniker 和 IBinding 接口，以及
客户端（比如 MSHTML）实现
IBindStatusCallback 和一些
相关接口，例如
IHttpNegotiate 或 IAuthenticate。
接下来是异步可插拔
协议处理程序。一个APP封装了
特定协议的详细信息，
例如 http、文件或 res。
...
大多数时候，一个应用程序
托管 WebBrowser 控件（或 BHO
在 IE 内部运行）使用高级
WebBrowser 提供的服务和
MSHTML 对象。然而，有时
这些服务还不够，而且
需要较低级别的钩子。
...
如果能上钩就太好了
进入通信序列
WebBrowser/MSHTML 和 URL 之间
绰号。不幸的是，确实有
似乎没有办法做到这一点 - 在
至少据我所知，没有一个。所以，我们
看看下一个级别 - a
URL 名字对象之间的通信
和一个应用程序。
...
现在，很少需要
实施一个完整的APP
从头开始 - 毕竟，多久做一次新的
协议实际上已经定义了吗？但
为了我们的目的，这是有用的
实现一个所谓的passthrough APP
（pAPP）。 pApp 是一个对象
实现 URL 两侧
名字到APP的通信，即
它实现了 IInternetProtocol
和 IInternetProtocolSink /
IInternetBindInfo。我们将其注册为
标准的临时处理程序
协议，例如 HTTP。现在每当
需要发送一个HTTP请求，URL
名字将创建我们的一个实例
pAPP 并要求它完成这项工作。这
然后 pAPP 创建一个实例
协议的标准APP
问题（我称之为目标APP，或者
tAPP，但请注意，这是我发明的
我自己的术语，不是
被广泛接受的建议
欢迎更好的命名约定）
并充当其客户。在此刻，
我们的 pAPP 成为众所周知的
中间人。在最简单的
情况下，通过 URL 进行的任何方法调用
pAPP 上的名字被转发到 tAPP，
以及 tAPP 上进行的任何方法调用
pAPP 被转发回 URL Moniker。
pAPP 开始观察，如果
想要的，修改每一点
与此请求相关的信息
之间来回传递
绰号和 tAPP。

Igor 有几个示例项目，应该有助于编写您自己的 pAPP：

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.