Pull to refresh

О необходимости внесения поправок в HTML 5

Reading time4 min
Views634
Нынешний проект HTML 5 содержит функцию registerProtocolHandler() в таком виде, который не особенно пригоден ко практическому употреблению. И нелишне будет рассказать о том, как я пришёл к такому выводу.

Рассказ будет обширен; кто не чувствует в себе резервов терпения, тем лучше под хабракат не лазать.

Году примерно в 2007 или в 2008 был открыт сайт http://fghi.pp.ru/ он работает как гейт между фидонетовской системою эхопочты и браузерами наподобие Файерфокса. Например, ежели у кого нету прямого доступа к Фидонету, и потому он не может прямо открыть фидонетовское сообщение, имеющее URL

      area://Ru.Blog.Mithgol?msgid=2:5063/88+49659a64

то зато он может использовать веб-гейт, открыв URL

      http://fghi.pp.ru/?area://Ru.Blog.Mithgol?msgid=2:5063/88+49659a64

Гейт этот обрабатывает несколько схем FGHI URL (таких, как «area://...» и «fecho://...») для фидонетовских гиперссылок.

В прошлом же году появился Firefox 3.0.x — браузер, реализовавший предложение WhatWG насчёт API registerProtocolHandler(). Вебсайтам стало возможно регистрироваться в качестве обработчиков для схем URLов, прежде неизвестных браузеру. Для схем, подобных FGHI URL Фидонета, прежде остававшихся совершенно неведомыми для браузеров Интернета, хотя постепенно они воплощалися во браузерах Фидонета (таких, как HellEd и NoSFeRaTU's GoldED+).

Я без промедления поведал о том фидонетовской эхопочтою автору FGHI URL гейта и объяснил ему достоинства registerProtocolHandler():

      area://GanjaNet.Local/?msgid=2:5063/88+48319a1f

Тогда автор FGHI URL гейта создал страницу http://fghi.pp.ru/handler.php в качестве места, которое кто угодно может посетить и зарегистрировать гейт в качестве обработчика гиперссылок «area://» и «fecho://» в Файерфоксе.

Однако, даже после того, как этакая регистрация завершена, читатель посещает страницы наподобие http://fghi.pp.ru/?area://FTSC_Public/ и видит там URLы в загейтованном виде, типа такого:

      http://fghi.pp.ru/?area://FTSC_PUBLIC?msgid=2:280/5555+48c0e781

Я спросил автора гейта, отчего URLы не предоставляются тогда в их естественном фидонетовском виде, типа такого:

      area://FTSC_PUBLIC?msgid=2:280/5555+48c0e781

Автор гейта тогда объяснил мне, что WhatWG API неполон и не обеспечивает сайту никакого способа определить, был ли вызов registerProtocolHandler() успешным, была ли схема URLа в действительности зарегистрирована, остаётся ли она зарегистрированною до той поры, когда очередная страница отдаётся сервером.

Для меня стало совершенно очевидно, что HTML 5 надобно дополнить, чтобы и эта задача могла выполняться невозбранно.

Возможно, функцию registerProtocolHandler() нынешнего стандарта HTML 5 уместно оставить void (не возвращающей значение), как сейчас записано в стандарте; однако WhatWG не мешало бы изобрести новую булевскую (логическую) функцию с именем наподобие protocolRegistered("area") и с единственным аргументом — именем протокола — для проверки, зарегистрирован ли протокол.

На http://www.whatwg.org/specs/web-apps/current-work/#custom-handlers перечислены возможные последствия такой регистрации протоколов в плане их безопасности. Лично мне приходят на ум следующие два соображения:

1) Браузер должен предотвращать «захламление», «заспамливание» пользователя джаваскриптовыми запросами о регистрации, даже если сайт вознамерится вызывать функцию registerProtocolHandler() до тех пор, покуда protocolRegistered() не возвратит истинное значение. На странице http://fghi.pp.ru/handler.php я приметил ужé, что Firefox показывает свои уведомления последовательно («fecho://» после «area://» и только если регистрация «area://» пользователем была принята или отклонена); этой меры, вероятно, и довольно.

2) Сайт не должен мочь торговаться за регистрацию протокола; например, сценарий «чтобы залогиниться в архив порно, зарегистрируйте тут ваш обработчик «mailto:» и тем дозвольте нам собирать адреса ваших корреспондентов для рассылки спама им» должен беспременно быть предотвращён. Простой галочки в интерфейсе браузера при регистрации схемы («Я регистрирую evil.example.org как обработчик только тех mailto-ссылок, которые появляются на самом evil.example.org».) было бы достаточно для того, чтобы сайт видел protocolRegistered() истинным и даже мог проверить, что гиперссылка «mailto:example@evil.example.org», когда жмякнули по ней мышою, привела на страницу обработчика на том сайте — но никакого другого вреда этого не приносило бы.

Кое-кому могло бы прийти в голову, что функция protocolRegistered("area") могла бы возвращать не просто логическую истину, но и прямо гиперссылку (в вышеприведённом примере, «http://fghi.pp.ru/?%s»). Однако эдак во внешнюю Сеть запросто могли бы утечь интранетовские адреса страниц-обработчиков. А кроме того (и это, пожалуй, ещё повесомее будет), тогда сайты-обработчики могли бы использовать собственные префиксы вместо того, чтобы подавать нестандартные адреса в естественном их виде, если и когда было бы заметно, что пользователь предпочитает (и зарегистрировал в качестве обработчика естественного вида нестандартных URLов) некоторый другой сайт, сайт конкурентов. Это было бы настолько очевидной гадостию, что я полагаю двоичную функцию protocolRegistered() наилучшим выходом.

Вот и вся история о том, отчего одной функции registerProtocolHandler() недостаточно.

Теперь я обращаюсь к Хабру с вопросом: каким образом можно переломить ситуацию? Есть ли на Хабре лица со связями в WhatWG и (или) в браузеростроительной отрасли, которые способны повлиять на принятие решений и начертать API регистрации схем URLов в более законченном, в более удобном для сайтостроителей виде?
Tags:
Hubs:
Total votes 20: ↑7 and ↓13-6
Comments17

Articles