The ability to filter all incoming HTTP requests is
powerful and seductive because it enables you to monitor and filter all
content, regardless of content type, before it ever reaches the user's browser.
The use of WinInet within a pluggable protocol exposes a far richer set of
network notifications than either the Asynchronous Pluggable Protocol (APP)
environment or moniker binding. This leads you to one of two options:
- Replace the default HTTP handler.
- Create a new protocol (for example, x-filterhttp://) that
acts just like the HTTP protocol.
However, this approach is fraught with difficulties:
- Internet Explorer ignores naive attempts to overwrite HKEY_CURRENT_ROOT\PROTOCOLS\Http with a value other than the CLSID for IID_IOInetBindClient.
- You will not be able to trap download requests for oft-used
components that do not retrieve their resources through URL Monikers, the best
example being Java .class files. The URL Monikers library, URLMON, implements
the pluggable protocol architecture. Individual handlers, like the default
handlers for HTTP and FTP, use WININET for their networking. The Java Runtime
is hosted in Internet Explorer as an ActiveX control, and any .class file
specified in an APPLET tag is fed to it as a property bag name-value pair. The
Runtime downloads these files using WININET; URLMON never sees these requests,
and thus cannot invoke a pluggable protocol to handle them.
- It is difficult to wrap all WinInet functionality. You will
encounter several problems, such as disappearing HttpContext values in your
INTERNET_STATUS_CALLBACK handler and crashes on HTTP redirect that take profuse
amounts of code and time to overcome.
- WinInet does not handle all aspects of HTTP transmissions.
Some sites use content encoding on their documents, which causes the server and
the browser to compress and decompress documents on the fly for faster
transmission over the network. The default HTTP protocol handler in URLMON
handles decompression in Internet Explorer. However, a custom pluggable
protocol handler will bypass the default HTTP protocol handler in URLMON.
Custom protocols must decompress the data themselves and inform URLMON of the
decompression by using the BINDSTATUS_DECODING flag in the IInternetProtocolSink::ReportProgress method.
- If you wrap HTTP in a custom protocol handler, such as
x-filterhttp://, you create problems with security context. Suppose that a
FRAMESET page downloads as x-filterhttp://www.site.com/ (the linked URL or the
URL that the user types) while all of its contained pages continue to download
through the http:// protocol. If any script tries to access objects across
frames, a "Permission Denied" security error is raised, which causes the
application to run differently under your custom protocol than under normal
HTTP. This occurs because when you alter a URL's protocol, you alter its
security context.For additional information,
click the article number below to view the article in the Microsoft Knowledge
Base:
167796 PRB: Permission Denied Error Message When Scripting Across Frames
- Unless you rewrite all of a page's URLs dynamically as the
page downloads through your APP, a page that includes a mix of relative,
virtual, and absolute links will have its objects downloaded through different
protocols, which could potentially alter the behavior of your
application.
If you must use an APP to handle a specific HTTP URL, you can
use a temporary Pluggable Namespace handler for this purpose.
For additional information, click the
article number below to view the article in the Microsoft Knowledge Base:
190893 BUG: Registry Patterns Ignored for Pluggable Namespace Handlers
Note You should only use this technique if you somehow want to
transform the contents of the retrieved data before it hits the client, or if
you are truly using a different protocol scheme (such as a direct TCP/IP
connection, Named Pipes, or network file access) to retrieve the addressed
content.