Registering an Application to a URL Protocol
The About Asynchronous Pluggable Protocols article describes how to develop handlers for URL protocols. In some cases, it may be desirable to invoke another application to handle a custom protocol. To do so, register the existing application as a URL Protocol handler. Once the application has successfully launched, it can use command-line parameters to retrieve the URL that launched it. These settings apply to protocol handlers launched from within Windows Internet Explorer and from Windows Explorer using the Run... command (Windows logo key+R).
This topic contains the following sections:
- Registering the Application Handling the Custom Protocol
- Launching the Handler
- Security Issues
- Example Protocol Handler
- Related Topics
Registering the Application Handling the Custom Protocol
To register an application to handle a particular URL protocol, add a new key, along with the appropriate subkeys and values, to HKEY_CLASSES_ROOT. The root key must match the protocol scheme that is being added. For instance, to add an "alert:" protocol, add an alert key to HKEY_CLASSES_ROOT, as follows:
alert
URL Protocol = ""
Under this new key, the URL Protocol string value indicates that this key declares a custom protocol handler. Without this key, the handler application will not launch. The value should be an empty string.
Keys should also be added for DefaultIcon and shell. The Default string value of the DefaultIcon key must be the file name to use as an icon for this new URL protocol. The string takes the form "path, iconindex" with a maximum length of MAX_PATH. The name of the first key under the shell key should be an action verb, such as open. Under this key, a command key or a DDEEXEC key indicate how the handler should be invoked. The values under the command and DDEEXEC keys describe how to launch the application handling the new protocol.
Finally, the Default string value should contain the display name of the new protocol. The following example shows how to register an application, alert.exe in this case, to handle the alert protocol.
alert
(Default) = "URL:Alert Protocol"
URL Protocol = ""
DefaultIcon
(Default) = "alert.exe,1"
shell
open
command
(Default) = "C:/Program Files/Alert/alert.exe" "%1"
When a user clicks a link registered to your custom URL protocol, Internet Explorer launches the registered URL protocol handler. If the specified open command specified in the registry contains a %1 parameter, Internet Explorer passes the URL to the registered protocol handler application.
Launching the Handler
By adding the above settings to the registry, navigating to URLs such as alert:Hello%20World
would cause an attempt to launch alert.exe with the complete URL on the command line. Internet Explorer decodes the URL, but the Windows Run... command does not. If a URL contains spaces, it may be split across more than one argument on the command line.
For example, if the link above is followed through Internet Explorer, the command line would be:
If this link is followed through Windows Explorer, the Windows Run command, or some other application, the command line would be:
Because Internet Explorer will decode all percent-encoded octets in the URL before passing the URL to ShellExecute, URLs such as alert:%3F?
will be given to the alert application protocol handler as alert:??
. The handler won't know that the first question mark was percent-encoded. To avoid this issue, application protocol handlers and their associated URL scheme must not rely on encoding. If encoding is necessary, protocol handlers should use another type of encoding that is compatible with URL syntax, such as Base64 encoding. Double percent-encoding is not a perfect solution either; if the application protocol URL isn't processed by Internet Explorer, it will not be decoded.
When ShellExecute executes the application protocol handler with the URL on the command line, any non-encoded spaces, quotes, and slashes in the URL will be interpreted as part of the command line. This means that if you use C/C++'s argc and argv to determine the arguments passed to your application, the URL may be broken across multiple parameters. To mitigate this issue:
- Avoid spaces, quotes, or backslashes in your URL
- Quote the %1 in the registration ("%1" as written in the 'alert' example registration)
However, avoidance doesn't completely solve the problem of quotes in the URL or a backslash at the end of the URL.
Security Issues
As noted above, the URL that is passed to an application protocol handler might be broken across multiple parameters. Malicious parties could use additional quote or backslash characters to pass additional command line parameters. For this reason, application protocol handlers should assume that any parameters on the command line could come from malicious parties, and carefully validate them. Applications that could initiate dangerous actions based on external data must first confirm those actions with the user. In addition, handling applications should be tested with URLs that are overly long or contain unexpected (or undesirable) character sequences.
For more information, please see Writing Secure Code.
Example Protocol Handler
The following sample code contains a simple C# console application demonstrating one way to implement a protocol handler for the alert protocol.
using System; using System.Collections.Generic; using System.Text; namespace Alert { class Program { static string ProcessInput(string s) { // TODO Verify and validate the input // string as appropriate for your application. return s; } static void Main(string[] args) { Console.WriteLine("Alert.exe invoked with the following parameters./r/n"); Console.WriteLine("Raw command-line: /n/t" + Environment.CommandLine); Console.WriteLine("/n/nArguments:/n"); foreach (string s in args) { Console.WriteLine("/t" + ProcessInput(s)); } Console.WriteLine("/nPress any key to continue..."); Console.ReadKey(); } } }
When invoked with the URL alert:"Hello%20World"
(note extra quotes) from Internet Explorer, the program responds with:
Alert.exe invoked with the following parameters. Raw command-line: "C:/Program Files/Alert/alert.exe" "alert:"Hello World"" Arguments: alert:Hello World Press any key to continue...
Related Topics
I have registered a URL protocol along with the application installation, and it works flawlessly on both IE and firefox. The problem is that on a computer on which the application is not installation( neither is the URL protocol registered), and the user clicks the URL link. I would like the IE to open a javascript windows, or a web page, or something else, to give the user a choice to install the application.
Q: How to do that?
A: Sadly, there's no way to do this directly (e.g. no window.navigator.supportsProtocol() method). You could register in the VersionVector and use Conditional Comments in IE to detect the presence of your handler.
- 12/3/2010
- XHPO
- 1/17/2011
- EricLaw [MSFT]
A: All major browsers on Windows will pick up Application Protocols registered in this way.
- 7/2/2010
- Cubud
- 1/17/2011
- EricLaw [MSFT]
- 9/8/2010
- Benjamin Eberlei
- 6/8/2010
- Evgeniy Dolzhenko
==================
Try converting the custom URL with tinyurl.com. It will return an http protocol URL and will forward to your custom URL (making it clickable in Outlook, etc).
-Donavon
- 12/8/2009
- Vadim Rapp
- 1/7/2010
- i am donavon
- 9/14/2009
- clavazzi
- 6/20/2008
- Dee
- 8/28/2009
- Thomas Lee
So far this works great on IE7 using the "command" key, however for some reason it does not work in IE6. I'm getting an "Invalid Systax Error" when I click on the link from within the browser. Everything works great if I type the URL on the "START > Run..." window. I'm not sure if the "DDEEXEC" key is required by IE6 though. If so, please can you provide an example?
- 8/14/2008
- MiguelGuzman
- 5/19/2009
- Thomas Lee
I have built a small tool for regestering URL protocols: http://www.codeplex.com/CustomURL
This tool will help you register URL protocols and lauch a specific application when a URL is executed. This tool is free and open source.
- 7/8/2008
- kallelundberg
- 1/18/2009
- Stanley Roark
This works great except that an IE window is left open showing the URI that was invoked. Is there any way (e.g. a value in the registry, EditFlags perhaps) to make this window close or not appear in the first place?
=> The problem with the blank IE window may be related to the zone where the page that hosts the link is located. If you test a html page form the file system (file://... ) try to host the page in IIS instead (so that it is http://...) - this worked for me.