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:
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.
(Default) = "URL:Alert Protocol"
URL Protocol = ""
(Default) = "alert.exe,1"
(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 URI 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:
"C:\Program Files\Alert\alert.exe" "alert:Hello World"
If this link is followed through Windows Explorer, the Windows Run command, or some other application, the command line would
"C:\Program Files\Alert\alert.exe" "alert:Hello%20World"
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.
Internet Explorer 9. An application protocol handler can disable URL percent decoding by adding the UseOriginalUrlEncoding setting to
the registration for the protocol. When this setting is set to (DWORD) 1, the command line is not percent decoded by Internet Explorer
when passed to the protocol handler.
Warning The use (or lack) of URL percent encoding does not protect a protocol handler from malicious input. Care must be taken to
properly validate input from untrusted sources.
As noted above, the URL that is passed to an application protocol handler might be broken across multiple parameters. Malicious parties
could use additional quotation marks 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.
Example Protocol Handler
The following sample code contains a simple C# console application demonstrating one way to implement a protocol handler for the alert
static string ProcessInput(string s)
// TODO Verify and validate the input
// string as appropriate for your application.
static void Main(string args)
Console.WriteLine("Alert.exe invoked with the following parameters. ");
Console.WriteLine("Raw command-line: " + Environment.CommandLine);
Console.WriteLine(" Arguments: ") foreach (string s in args)
Console.WriteLine(" " + ProcessInput(s));
Console.WriteLine(" Press any key to continue...");
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.
"C:\Program Files\Alert\alert.exe" "alert:"Hello World"
We have included a sample registry entry you can download('MailTo-WLM.reg') by clicking here.
After extracting the zip file you can add the .reg file to your registry. The sample file is a URL for the email Protocal. You can edit the file before its installed and change its
command line to another application of your choice, but keep the format the same to avoid problems or errors. You can also edit the key with regedit after its added to the registry by going to:
Then in the right panel change (Default) Key to:
"C:\Program Files\Windows Mail\WinMail.exe" /mailurl:%1
or the mail client path of your choice. Note: the above works with Windows XP through Windows 7.
Thanks for visiting mswintips.com.
Return to Index Page
Copyright ©2018 CSN All Rights Reserved