BUG: IE Can't Open Registered Helper App for URL with Spaces

Exención de responsabilidades de contenido KB retirado

Este artículo se refiere a productos para los que Microsoft ya no ofrece soporte técnico. Por tanto, el presente artículo se ofrece "tal cual" y no será actualizado.


Attempting to invoke a helper application via an HTML link or Internet Explorer address bar with a URL of the form "telnet://some%20URL%20encoded%20string" results in the following error message from Internet Explorer 4.0:

Internet Explorer cannot open the helper application for
"telnet://some url encoded string/".
The protocol specified in this address is not valid. Make sure the
address is correct, and try again.


URLs with embedded spaces, whether they have been URL encoded to %20 or not, are automatically converted to a form that prevents Internet Explorer 4.0 from correctly locating the registered helper application.


Change all "%20" encoded spaces to "%2520". This has the effect of double- encoding, which helps Internet Explorer handle the protocol correctly. For example, change




Microsoft has confirmed that this is a bug in the Microsoft products that are listed at the beginning of this article.

More Information

This bug is related to the documentation in the Internet Client SDK (InetSDK) under the following topic:

Internet Client SDK: Internet Tools & Technologies; Monikers, URLs, Security Zones, and Pluggable Protocols; Overview; Appendix B: Registering an Application to a URL Protocol
As an example, this section illustrates the technique of registering an application for a protocol. The documentation shows how to register Notepad.exe as the handler for URLs of the form "note:c:\myfile.txt"

First of all, Notepad does not work correctly in this situation, as might be expected after reading this appendix in the InetSDK. When Internet Explorer 4.0 processes "note:c:\myfile.txt," it executes Notepad and passes the entire URL to it. Because Notepad does not understand URLs such as "note:c:\myfile.txt," it does not open the c:\myfile.txt file as expected.

The "telnet:" protocol is an example of an application (TELNET) registered in a similar manner by Internet Explorer 4.0 when it is installed. TELNET works as expected because the registered shell command under HKEY_CLASSES_ROOT\telnet\shell\open\command points to a routine in Url.dll that strips off the "telnet://" part and invokes Telnet.exe with the rest of the URL.

Second, as this article describes, if a URL contains spaces when it is invoked, "note:c:\program files\my file name with spaces.txt" for example, Internet Explorer fails to execute Notepad at all. An error message similar to the one listed under the SYMPTOMS section earlier appears.

Because spaces are invalid characters in correct URLs, the proper form of the above example would be "note:c:\program%20files\my%20file%name." Unfortunately, this example does not work correctly either, as Internet Explorer pre- converts the %20's back to spaces before passing the string on to the shell to execute.

For custom protocols such as "note:" that must support spaces in the URL, there are two alternatives. The first is to use the workaround described in RESOLUTION above. As a second possibility, the "Monikers, URLs, Security Zones, and Pluggable Protocols" documentation in the InetSDK describes a more complete method for handling custom protocols. Following the directions therein related to creating a "Pluggable Protocol Handler" would allow any application to correctly handle any URL form. Please refer to this documentation for more information on pluggable protocols.

Outlook uses this method to register the "outlook:" protocol. Because of the bug mentioned in this article, URLs with spaces such as "outlook:\\public%20folders\all%20public%20folders" will fail as hyperlinks within Web pages while URLs without spaces such as "outlook:inbox" will succeed.


Internet Client SDK: Internet Tools & Technologies; Monikers, URLs, Security Zones, and Pluggable Protocols; Overview; Appendix B: Registering an Application to a URL Protocol


Id. de artículo: 176347 - Última revisión: 06/22/2014 - Revisión: 1