Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

There is no server-side way to determine whether a specific URL scheme is registered #10

Mithgol opened this Issue Oct 25, 2011 · 1 comment


None yet
2 participants

Mithgol commented Oct 25, 2011


Imagine that registerProtocolHandler() is successfully called, and some given site is registered as a handler for some non-standard URL scheme.

What happens then?

We have isProtocolHandlerRegistered() on the client side to check that registration.

On the other hand, unfortunately, there is no way for a server-side application to determine whether a specific URL scheme is available on the client.

That's why, in server-generated content, any non-standard URL schemes inevitably become prefixed nevertheless. Prefixed to guarantee their safety. (That is, to guarantee that they would actually work.) Prefixed by the name of some handler site, known by the server script's author — but not necessarily the same handler that was registered by registerProtocolHandler() on the client side.


For example, let's imagine that we have non-standard area:// URL scheme registered.

Any server script has to refrain from making <a href="``area://Ru.FTN.Develop/?msgid=2:5063/88+4a0d1707``"> because, as you may have already guessed, the server does not know (cannot know) whether simple area://… URLs are safe there; it does not know whether any handler have been registered for such URLs.

The server script has to use significantly longer (and prefixed) form, such as <a href="http://fghi.pp.ru/?``area://Ru.FTN.Develop/?msgid=2:5063/88+4a0d1707"> (where http://fghi.pp.ru/ is the URL handler server that has to appear as a prefix). It is longer, but it is safe.

Of course, it seems to effectively defeat the purpose of isProtocolHandlerRegistered().

A side note: the example is partially real

The draft area://Ru.FTN.Develop/?msgid=2:5063/88+4a0d1707 actually defines area:// URLs, and fghi.pp.ru is currently one of their handler sites (the hostname may change in the future).

However, that site does not call isProtocolHandlerRegistered() because the function is not currently implemented in any browser.


The site may, of course, call isProtocolHandlerRegistered() function on each page, and set a cookie to indicate whether that function returns registered.

However, there are the following problems:

  1. The cookie is, naturally, non-existent before the first visit. The URLs should appear prefixed (which is not efficient), or the page should instantly reload itself on the first visit (which is, most likely, even more inefficient).
  2. If isProtocolHandlerRegistered() does not return registered but the cookie says the handler was previously registered, then the cookie has to be reset and the page has to be reloaded instantly (which is also not efficient).
  3. The user can disable cookies. (Which can in turn be worked around; for example, with PHP session ID as a GET parameter; but still — — —)
  4. Even if isProtocolHandlerRegistered() does return registered, the value is not reliable. The current spec says that value means «the given handler has been registered or the site is blocked from registering the handler». If the site is blocked, then we still have zero information about whether handler://... URLs are safe.

(A side note: the last problem is a serious client-side problem as well.)

Proposed solution

Make a new HTTP request header and name it Accept-URL-Schemes (similar to Accept-Charset, Accept-Encoding, Accept-Language, Accept-Ranges).

Let that header contain the complete and reliable list of URLs the user-agent is willing to expect in <a href="…"> and in similar attributes and properties (willing to expect, willing to accept, and is ready to activate them on click or otherwise) in the Web content.


Accept-URL-Schemes: http, https, mailto, tel, sms, mms, news, nntp, irc, ircs, skype, ed2k, bitcoin, facetime, magnet, steam, view-source, some-other-non-standard-scheme

Security and privacy concerns

  • The browser should prevent continous registration spamming. Even if the site continuously runs registerProtocolHandler() until Accept-URL-Schemes contains some scheme, the user MUST be given an option to break that loop. However, intentionally adding wrong values to Accept-URL-Schemes list should not be used as the method of breaking that loop; the user will probably not be happy if finally silently gets a list of links that cannot be activated.
  • A site should be prevented from being able to bargain for protocol registering. For example, the scenario «in order to login for porn, register your mailto handler here and allow us to harvest your addressees for spam» should not be made possible. A mere checkbox («I register evil.example.org as a handler for mailto links that appear on the pages of evil.example.org only.») should be enough for the site to see mailto in Accept-URL-Schemes (and even to verify that with some mailto:example@evil.example.org link, which, when clicked on the evil site, will actually lead to the same site's handler page), but no other harm would occur.

leobalter commented Apr 22, 2016

have we got any update on this? I'm closing but this can be re-opened if necessary.

@leobalter leobalter closed this Apr 22, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment