INFO: Implementing HTTP-like Asynchronous Pluggable Protocols (303740)

MORE INFORMATION

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: 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.