jquery/standards — Issue #10: There is no server-side way to determine whether a specific URL scheme is registered
Author: Mithgol
Created: 2011-10-25 11:59:59+00:00
State: open

## Problem

Imagine that [registerProtocolHandler()](http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#custom-handlers "WhatWG HTML5, section 7.5.1.2: Custom scheme and content handlers") is successfully called, and some given site is registered as a handler for some non-standard URL scheme.

What happens then?

We have [isProtocolHandlerRegistered()](http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#custom-handlers "WhatWG HTML5, section 7.5.1.2: Custom scheme and content handlers") 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()](http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#custom-handlers "WhatWG HTML5, section 7.5.1.2: Custom scheme and content handlers") on the client side.

## Example

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

Any server script has to refrain from making `` 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 `` (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()](http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#custom-handlers "WhatWG HTML5, section 7.5.1.2: Custom scheme and content handlers").

### A side note: the example is partially real

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

However, that site does not call [isProtocolHandlerRegistered()](http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#custom-handlers "WhatWG HTML5, section 7.5.1.2: Custom scheme and content handlers") because the function is not currently implemented in any browser.

## Workaround

The site may, of course, call [isProtocolHandlerRegistered()](http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#custom-handlers "WhatWG HTML5, section 7.5.1.2: Custom scheme and content handlers") function on each page, and set a cookie to indicate whether that function returns `registered`.

However, there are the following problems:

0. 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).

0. If [isProtocolHandlerRegistered()](http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#custom-handlers "WhatWG HTML5, section 7.5.1.2: Custom scheme and content handlers") 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).

0. The user can disable cookies. (Which can in turn be worked around; for example, with PHP session ID as a GET parameter; but still — — —)

0. Even if [isProtocolHandlerRegistered()](http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#custom-handlers "WhatWG HTML5, section 7.5.1.2: Custom scheme and content handlers") **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 `` 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.

Example:

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