В общем потоке новостей остался незамеченным совместный призыв продукт-менеджера Chrome Кенджи Бахе и веб-консультанта Google Юсуке Уцуномии об использовании нового стандарта Web Bundles, разработанного Google. На chromium.googlesource появился соответствующий мануал по использованию WebBundles и, собственно, особо о нем больше не говорилось. Запись от лица Базе и Уцуномии была опубликована еще в ноябре 2019 года, но вызвала реакцию сообщества только сейчас, и то, исключительно на нескольких профильных площадках и в одном блоге, посвященном кибербезопасности.



Чем так опасна технология упаковки содержимого веб-страницы в один источник, что это вообще такое, и почему команда веб-разработки Google ступает на очень скользкую дорожку, давайте разбираться ниже.

Web Bundle дело RarJPEG живет

Конкретно о WebBundle писали на Хабре в уже достаточно далеком 2015 году. Тогда автор ComodoHacker выпустил статью "Web Bundle дело RarJPEG живет" с обзором свежего релиза нового инструмента на GitHub.

Принцип WebBudle образца 2015 года прост и дублирует принципы упаковки .exe-файлов: произвольные файлы упаковываются в один файл-контейнер, а на клиентской стороне доступ к ним организуется по имени файла с помощью API.

Релиз 2015 года фактически, был переосмыслением знакомым с имиджбордами пользователям, принципа rarJPEG когда в изображение упаковывалось дополнительное содержимое. Это позволяло обходить ограничения борд на загрузку только изображений и передавать произвольные файлы между пользователями с помощью анонимной платформы.

WebBundle все так же был направлен на обход ограничений по типу файлов: с его помощью в условный PNG можно было запаковать что угодно, вплоть до бинарников, и передать под видом картинки одним архивом.

В 2015 году ComodoHacker очень правильно оценил перспективы WebBundle: технология специфичная и она будет жить, только если ей найдется применение. Сейчас, из 2020 года мы можем смело ответить, что нет, применения технологии не нашлось и в свет она не пошла.

Вот только проблема в том, что в рядах инженеров и веб-разработчиков Google определенно есть завсегдадаи Форчана, и они переосмыслили концепцию WebBundle, выпустив в свет версию 2.0 или, как они сами ее назвали, WebBundles.

Чем WebBundles 2019 года от Google отличается от WebBundle 2015 года

Первое и очевидное за работу взялись ребята из Google. Второе вроде бесполезную сову упаковки в PNG рандомных файлов они сумели натянуть на огромный глобус веб-разработки и сайтостроения.

Если давать TL;DR, то разница между WebBundles и WebBundle выглядит примерно вот так:



Инженеры Google прямо предлагают использовать WebBundles для инкапсуляции нескольких источников в один файл для последующего его отображения в качестве итоговой веб-страницы для пользователя. Фактически, наиболее близкая из существующих сейчас технологий это PDF. Думаю, многие из нас сталкивались хоть раз в своей жизни с необходимостью извлечь из PDF-файла часть его содержимого и в дальнейших комментариях это не нуждается.

Но если Google станет продвигать WebBundles как повсеместный инструмент, для веба могут настать крайне мрачные времена, и вот почему.

Чем опасен WebBundles для современного веба

Современный веб построен на принципе, что для каждого источника есть своя ссылка, то есть мы можем провести декомпиляцию страницы и посмотреть ее содержимое, зачастую, буквально через открытие консоли в браузере.

В случае с упаковкой сайта в WebBundles мы получаем монолит из десятков или сотен инкапсулированных источников, которые для внешнего мира скрываются под одной ссылкой, а вызов этого содержимого возможен только при прямом обращении к нашему монолиту.

С точки зрения информационной безопасности это означает, что любой сайт, который для внешнего мира представляется просто как условная моно-ссылка, внутри себя может содержать произвольный JS-код, скрипты, рекламу и так далее, на что хватит фантазии.

Исследователь в области информационной безопасности из компании компании Brave Питер Снайдер так отозвался в своем блоге о созданной Google технологии:

Эта технология может превратить современный интернет из набора ресурсов с гиперссылками (которые можно проверять, выборочно получать или даже заменять) на непрозрачные пузыри, которые работают по принципу все или ничего (например, как уже работают PDF или SWF).

Проблема WebBundles в том, что сам принцип непрозрачной упаковки содержимого веб-страницы в единый монолит делает невозможным проверки, плюс обесценивает уже выстроенный механизм значимости и индексации URL-адресов.

По сути, общая проблема всех этих трюков с упаковкой заключается в том, что WebBundles создают локальное пространство имен, независимо от того, что видит остальной мир. В итоге это может вызвать огромную путаницу в именах и свести на нет годы работы по созданию конфиденциальной и безопасной среды.

Зачем это токсичный чемодан без ручки нужен Google

Сейчас будет озвучен всем известный факт: Google ненавидит блокировщики рекламы. Возможно, они стараются делать вид, что блокировщики это явление, с которым надо жить и которое никуда не денется. Возможно, они сами поддерживают этот мейнстрим. Например, в ноябре в Chrome добавили встроенный блокировщик.

Но давайте будем честны: вся империя Google держится на баннерах и первых трех ссылках поисковой выдачи с пометкой реклама. Это многомиллиардный доход корпорации и вокруг баннеров и этих трех ссылок крутится весь бизнес и империя разработки Google.

WebBundles может изменить правила игры на техническом уровне и сделать концепцию работы современных блокировщиков рекламы полностью недееспособной. В WebBundles можно упаковать рандомные URL для отображения рекламы, в них можно совершать подмену URL-адресов и так далее, на что у вас хватит фантазии.

При этом Google настроена достаточно серьезно. Текущая реализация WebBundles уже интегрирована в стабильные версии Chrome, но пока по умолчанию отключена. Но при желании по chrome://flags вы можете открыть этот ящик Пандоры.


Версия Chrome 85.0.4183.83 (Официальная сборка), (64 бит)

Сейчас WebBundles больше похоже на ружье, которое висит на стене и никогда не выстрелит. Но если Google сильно прижмет и доходы компании значительно просядут из-за падения рекламных бюджетов, в ход может пойти и это оружие. Что пообещает корпорация веб-разработчикам неизвестно, но уже точно понятно, что WebBundles выглядит очень аппетитно для недобросовестных веб-мастеров, которые готовы монетизировать свое хозяйство любыми путями и способами.

Как с этим бороться тоже непонятно, особенно с учетом того, что во главе возможного внедрения web-PDF будет стоять компания, которая занимается разработкой самого популярного браузерного движка на планете. Еще хуже то, что этому движку сейчас нет внятных альтернатив, потому что даже Microsoft уже как два года пристрелили и закопали свою стюардессу EdgeHTML, перейдя на Chromium.

Аналогия с PDF проведена не просто так: базовый принцип отображения и упаковки данных между форматом защиты документов и WebBundles крайне схож. Еще хуже то, что к 2020 году в широком доступе нет инструментов и сервисов (даже платных), которые бы со 100% точностью декомпилировали содержимое PDF и отдавали его пользователю в нужном формате, а мы говорим просто о защите текстовых данных. Какие способы защиты содержимое контейнеров WebBundles могут создать в Google остается только гадать.

Google пока аккуратно позиционирует WebBundles как инструмент для сохранения и передачи веб-сайтов в локальном виде, то есть через носители или Bluetooth. При этом компания называет WebBundles новым стандартом, который может коренным образом изменить интернет, то есть планы по широкому внедрению WebBundles уже есть.

---

На правах рекламы

Серверы для размещения сайтов любых масштабов это про наши эпичные! Все серверы из коробки защищены от DDoS-атак, скорость интернет-канала 500 Мегабит, автоматическая установка удобной панели управления VestaCP для размещения сайтов и даже автоматическая установка Windows Server на тарифах с 2 ГБ ОЗУ или выше. Поспешите заказать!

Доброго времени суток, друзья!

Представляю Вашему вниманию перевод заметки How to Parse URL in JavaScript: hostname, pathname, query, hash автора Dmitri Pavlutin.

Унифицированный указатель ресурса или, сокращенно, URL это ссылка на веб-ресурс (веб-страницу, изображение, файл). URL определяет местонахождения ресурса и способ его получения протокол (http, ftp, mailto).

Например, вот URL данной статьи:

https://dmitripavlutin.com/parse-url-javascript

Часто возникает необходимость получить определенные элементы URL. Это может быть название хоста (hostname, dmitripavlutin.com) или путь (pathname, /parse-url-javascript).

Удобным способом получить отдельные компоненты URL является конструктор URL().

В этой статье мы поговорим о структуре и основных компонентах URL.

1. Структура URL

Изображение лучше тысячи слов. На представленном изображении Вы можете видеть основные компоненты URL:

2. Конструктор URL()

Конструктор URL() это функция, позволяющая разбирать (парсить) компоненты URL:

const url = new URL(relativeOrAbsolute [, absoluteBase])

Аргумент relativeOrAbsolute может быть абсолютным или относительным URL. Если первый аргумент относительная ссылка, то второй аргумент, absoluteBase, является обязательным и представляет собой абсолютный URL основу для первого аргумента.

Например, инициализируем URL() с абсолютным URL:

const url = new URL('http://example.com/path/index.html')url.href // 'http://example.com/path/index.html'

Теперь скомбинируем относительный и абсолютный URL:

const url = new URL('/path/index.html', 'http://example.com')url.href // 'http://example.com/path/index.html'

Свойство href экземпляра URL() возвращает переданную URL-строку.

После создания экземпляра URL(), Вы можете получить доступ к компонентам URL. Для справки, вот интерфейс экземпляра URL():

interface URL {  href:     USVString;  protocol: USVString;  username: USVString;  password: USVString;  host:     USVString;  hostname: USVString;  port:     USVString;  pathname: USVString;  search:   USVString;  hash:     USVString;  readonly origin: USVString;  readonly searchParams: URLSearchParams;  toJSON(): USVString;}

Здесь тип USVString означает, что JavaScript должен возвращать строку.

3. Строка запроса (query string)

Свойство url.search позволяет получить строку запроса URL, начинающуюся с префикса ?:

const url = new URL(    'http://example.com/path/index.html?message=hello&who=world')url.search // '?message=hello&who=world'

Если строка запроса отсутствует, url.search возвращает пустую строку (''):

const url1 = new URL('http://example.com/path/index.html')const url2 = new URL('http://example.com/path/index.html?')url1.search // ''url2.search // ''

3.1. Разбор (парсинг) строки запроса

Вместо получения исходной строки запроса, мы можем получать ее параметры.

Легкий способ это сделать предоставляет свойство url.searchParams. Значением данного свойства является экземпляр интерфейса URLSeachParams.

Объект URLSearchParams предоставляет множество методов для работы с параметрами строки запроса (get(param), has(param) и т.д.).

Давайте рассмотрим пример:

const url = new Url(    'http://example.com/path/index.html?message=hello&who=world')url.searchParams.get('message') // 'hello'url.searchParams.get('missing') // null

url.searchParams.get('message') возвращает значение параметра message строки запроса.

Доступ к несуществующему параметру url.searchParams.get('missing') возвращает null.

4. Название хоста (hostname)

Значением свойства url.hostname является название хоста URL:

const url = new URL('http://example.com/path/index.html')url.hostname // 'example.com'

5. Путь (pathname)

Свойство url.pathname содержит путь URL:

const url = new URL('http://example.com/path/index.html?param=value')url.pathname // '/path/index.html'

Если URL не имеет пути, url.pathname возвращает символ /:

const url = new URL('http://example.com/');url.pathname; // '/'

6. Хеш (hash)

Наконец, хеш может быть получен через свойство url.hash:

const url = new URL('http://example.com/path/index.html#bottom')url.hash // '#bottom'

Если хеш отсутствует, url.hash возвращает пустую строку (''):

const url = new URL('http://example.com/path/index.html')url.hash // ''

7. Проверка (валидация) URL

При вызове конструктора new URL() не только создается экземпляр, но также осуществляется проверка переданного URL. Если URL не является валидным, выбрасывается TypeError.

Например, http ://example.com не валидный URL, поскольку после http имеется пробел.

Попробуем использовать этот URL:

try {    const url = new URL('http ://example.com')} catch (error) {    error // TypeError, "Failed to construct URL: Invalid URL"}

Поскольку 'http ://example.com' неправильный URL, как и ожидалось, new URL('http ://example.com') выбрасывает TypeError.

8. Работа с URL

Такие свойства, как search, hostname, pathname, hash доступны для записи.

Например, давайте изменим название хоста существующего URL с red.com на blue.io:

const url = new URL('http://red.com/path/index.html')url.href // 'http://red.com/path/index.html'url.hostname = 'blue.io'url.href // 'http://blue.io/path/index.html'

Свойства origin, searchParams доступны только для чтения.

9. Заключение

Конструктор URL() является очень удобным способом разбора (парсинга) и проверки (валидации) URL в JavaScript.

new URL(relativeOrAbsolute, [, absoluteBase] в качестве первого параметра принимает абсолютный или относительный URL. Если первый параметр является относительным URL, вторым параметром должен быть абсолютный URL основа для первого аргумента.

После создания экземпляра URL(), Вы можете получить доступ к основным компонентам URL:

• url.search исходная строка запроса
• url.searchParams экземпляр URLSearchParams для получения параметров строки запроса
• url.hostname название хоста
• url.pathname путь
• url.hash значение хеша

Автор сэр Тим Бернерс-Ли, изобретатель URI, URL, HTTP, HTML и Всемирной паутины, действующий глава W3C. Статья написана в 1998 году

Какой URI можно считать крутым?
Такой, который не изменяется.
Как изменяются URI?
URI не изменяются: их изменяют люди.

По идее, у людей нет никаких причин изменять URI (или прекращать поддерживать документы), но на практике их миллионы.

Теоретически, номинальный владелец пространства доменных имён действительно владеет пространством доменных имен и, следовательно, всеми URI в нём. Кроме неплатёжеспособности, ничто не мешает владельцу доменного имени сохранить это имя. И теоретически, пространство URI под вашим доменным именем полностью находится под вашим контролем, так что вы можете сделать его таким стабильным, как вам нравится. В значительной степени единственная веская причина для исчезновения документа из интернета заключается в том, что компания, которой принадлежало доменное имя, вышла из бизнеса или больше не может позволить себе поддерживать работу сервера. Тогда почему в мире так много пропавших ссылок? Отчасти это просто недостаток предусмотрительности. Вот некоторые причины, которые можно услышать:

Мы просто реорганизовали сайт, чтобы сделать его лучше.

Вам действительно кажется, что старые URI не могут больше работать? Если так, то вы выбрали их очень плохо. Подумайте о том, чтобы новые сохранились после следующего редизайна.

У нас так много материала, что мы не можем следить за тем, что устарело, что конфиденциально, а что ещё актуально, и поэтому мы подумали, что лучше просто отключить всё это.

Могу только посочувствовать. W3C пережила период, когда нам приходилось тщательно просеивать архивные материалы на предмет конфиденциальности, прежде чем сделать их достоянием общественности. Решение должно быть продумано заранее убедитесь, что вы фиксируете с каждым документом приемлемый круг читателей, дату создания и, в идеале, срок действия. Сохраните эти метаданные.

Ну, мы обнаружили, что нужно переместить файлы...

Это одно из самых жалких оправданий. Многие не знают, что веб-серверы позволяют вам управлять связью между URI объекта и фактическим его местонахождением в файловой системе. Представьте себе пространство URI как абстрактное пространство, идеально организованное. Затем сделайте отображение на любую реальность, которую вы на самом деле используете для её реализации. Затем сообщите об этом веб-серверу. Вы даже можете написать фрагмент своего сервера, чтобы сделать всё правильно.

Джон больше не поддерживает этот файл, теперь это делает Джейн.

Имя Джона было в URI? Нет, просто файл лежал в его директории? Ну понятно.

Раньше мы использовали для этого CGI-скрипт, а теперь используем двоичную программу.

Существует сумасшедшая идея, что страницы, созданные скриптами, должны быть расположены в области "cgibin" или "cgi". Это раскрывает наружу механизм того, как вы запускаете свой веб-сервер. Меняете механизм (даже сохраняя контент), и упс все ваши URI меняются.

Возьмём, к примеру, Национальный научный фонд (NSF):

Онлайн-документы NSF

http://www.nsf.gov/cgi-bin/pubsys/browser/odbrowse.pl

Первая страница для начала просмотра документов явно не останется такой через несколько лет. cgi-bin, oldbrowse и pl всё это выдаёт частицы информации о том, как-мы-делаем-это-сейчас. Если же вы используете страницу для поиска документа, то получаете первым столь же плохой результат:

Доклад рабочей группы по криптологии и теории кодирования

http://www.nsf.gov/cgi-bin/getpub?nsf9814

для индексной страницы документа, хотя сам html-документ выглядит гораздо лучше:

http://www.nsf.gov/pubs/1998/nsf9814/nsf9814.htm

Здесь заголовок pubs/1998 даст любому будущему архивному сервису хороший ключ к пониманию того, что действует старая схема классификации документов 1998 года. Хотя в 2098 году номера документов могут выглядеть иначе, но я могу себе представить, что этот URI всё ещё будет действителен, и он никак не помешает NSF или любой другой организации, которая будет поддерживать архив.

Я не думал, что URL-адреса должны быть постоянными были же URN.

Вероятно, это один из худших побочных эффектов обсуждения URN. Некоторые думают, что из-за исследований о более постоянном пространстве имён они могут небрежно относиться к висячим ссылкам, поскольку URN всё это исправят. Если вы один из этих людей, то позвольте вас разочаровать.

Большинство схем URN, которые я видел, выглядят как идентификатор авторитета, за которым следует либо дата и строка, которую вы выбираете, либо просто строка, которую вы выбираете. Это очень похоже на HTTP URI. Другими словами, если вы думаете, что ваша организация будет способна создавать долгоживущие URN, то докажите это сейчас, используя их для своих HTTP URI. В самом HTTP нет ничего, что делало бы ваш URI нестабильным. Только ваша организация. Создайте базу данных, которая сопоставляет URN документа с текущим именем файла, и позвольте веб-серверу использовать её для фактического извлечения файлов.

Если вы дошли до этого момента, то если у вас нет времени, денег и связей, чтобы разработать какое-то программное обеспечение, то вы можете заявить следующее оправдание:

Мы хотели, но у нас просто нет нужных инструментов.

А вот этому можно посочувствовать. Я полностью согласен. Что вам нужно сделать, так это заставить веб-сервер мгновенно обработать постоянный URI и вернуть файл, где бы он ни хранился в данный момент в вашей текущей сумасшедшей файловой системе. Вы хотите хранить все URI в файле в качестве проверки и постоянно поддерживать базу данных в соответствии с актуальностью. Вы хотите сохранить отношения между различными версиями и переводами одного и того же документа, а также сохранить независимую запись контрольной суммы, чтобы обеспечить защиту от повреждения файла случайной ошибкой. И веб-серверы просто не выходят из коробки с этими функциями. Когда вы хотите создать новый документ, ваш редактор просит задать URI.

Вам нужна возможность изменять владение, доступ к документу, уровень безопасности архивного уровня и прочее в пространстве URI без изменения URI.

Всё слишком плохо. Но мы исправим ситуацию. В W3C мы используем функциональность Jigedit (сервер Jigsaw для редактирования), которая отслеживает версии, и мы экспериментируем со скриптами создания документов. Если вы разрабатываете инструменты, серверы и клиенты, обратите внимание на эту проблему!

Это оправдание относится также ко многим страницам W3C, включая эту: так что делайте то, что я говорю, а не то, что я делаю.

Почему это должно меня волновать?

Когда вы меняете URI на своём сервере, вы никогда не можете полностью сказать, у кого будут ссылки на старый URI. Это могут быть ссылки с обычных веб-страниц. Закладки на вашу страницу. URI мог быть нацарапан на полях письма к другу.

Когда кто-то переходит по ссылке и она сломана, он обычно теряет доверие к владельцу сервера. Он также разочарован и эмоционально, и реально от невозможности достичь своей цели.

Много людей постоянно жалуются на битые ссылки, и я надеюсь, что ущерб очевиден. Надеюсь, что также очевиден репутационный ущерб мейнтейнеру сервера, где исчез документ.

Так что мне делать? Дизайн URI

Это обязанность веб-мастера выделять URI, которые можно будет использовать через 2 года, через 20 лет, через 200 лет. Для этого нужны продуманность, организованность и целеустремленность.

URI меняются, если в них меняется какая-то информация. Очень важно, как вы их проектируете. (Что, дизайн URI? Мне нужно проектировать URI? Да, вы должны подумать об этом). Проектирование в основном означает отсутствие какой-либо информации в URI.

Дата создания документа дата выдачи URI то, что никогда не изменится. Она очень полезна для разделения запросов, которые используют новую систему, от тех, которые используют старую систему. С неё хорошо начинать URI. Если на документе проставлена какая-то дата, даже если документ будет актуален в будущем, то это хорошее начало.

Единственным исключением является страница, которая намеренно является последней версией, например, для всей организации или большой её части.

http://www.pathfinder.com/money/moneydaily/latest/

Это последняя колонка Money Daily в журнале Money. Основная причина, по которой в этом URI не нужна дата, заключается в том, что нет никаких причин для сохранения URI, который переживёт журнал. Понятие Money Daily исчезнет тогда, когда исчезнет Money. Если вы хотите сослаться на контент, следует сослаться на него отдельно в архивах:

http://www.pathfinder.com/money/moneydaily/1998/981212.moneyonline.html

(Выглядит хорошо. Предполагает, что "money" будут означать одно и то же на протяжении всего существования pathfinder.com. Есть дублирование "98" и ненужный ".html", но в остальном выглядит как сильный URI.

Что оставить в стороне

Всё! Кроме даты создания, помещая любую информацию в URI, вы так или иначе напрашиваетесь на неприятности.

• Имя автора. Авторство может изменяться с появлением новых версий. Люди уходят из организаций и передают вещи другим.
  
• Предмет. Это очень сложно. Он всегда выглядит хорошо в первое время, но меняется удивительно быстро. Я расскажу об этом подробнее ниже.
  
• Статус. Каталоги типа старый, черновик и так далее, не говоря уже о последний и крутой, появляются во всех файловых системах. Документы меняют статус иначе не было бы смысла создавать черновики. Последняя версия документа нуждается в постоянном идентификаторе, независимо от его статуса. Держите статус вне имени.
  
• Доступ. В W3C мы разделили сайт на разделы для сотрудников, членов и публики. Это звучит хорошо, но, конечно, документы начинаются как командные идеи сотрудников, обсуждаются с членами, а затем становятся достоянием общественности. Действительно, обидно, если каждый раз, когда какой-то документ открывается для более широкого обсуждения, все старые ссылки на него ломаются! Теперь мы переходим к простому коду даты.
  
• Расширение файла. Очень распространённое явление. "cgi", даже ".html" изменятся в будущем. Возможно, через 20 лет вы не будете использовать HTML для этой страницы, но сегодняшние ссылки на неё ещё должны работать. Канонические ссылки на сайте W3C не используют расширение (как это делается).
  
• Программные механизмы. В URI ищите "cgi", "exec" и другие термины, которые кричат посмотрите, какое программное обеспечение мы используем. Кто-нибудь хочет посвятить всю жизнь скриптам Perl CGI? Нет? Тогда удалите расширение .pl. Прочитайте руководство сервера о том, как это сделать.
  
• Имя диска. Да ладно! Но я такое видел.

Так что лучший пример с нашего сайта это просто

http://www.w3.org/1998/12/01/chairs

отчёт о протоколе заседания председателей W3C.

Темы и классификация по темам

Более подробно расскажу об этой опасности, так как это одна из тех вещей, которые труднее всего избежать. Как правило, темы попадают в URI, когда вы классифицируете свои документы по выполняемой работе. Но эта разбивка изменится со временем. Названия областей изменятся. В W3C мы хотели изменить MarkUP на Markup, а затем на HTML, чтобы отразить фактическое содержание раздела. Кроме того, часто здесь плоское пространство имён. Через 100 лет вы уверены, что не захотите ничего повторно использовать? В нашей короткой жизни мы уже хотели повторно использовать Историю и Таблицы стилей, например.

Это заманчивый способ организации веб-сайта и действительно заманчивый способ организации чего угодно, включая всю Сеть. Это отличное среднесрочное решение но имеет серьёзные недостатки в долгосрочной перспективе.

Отчасти причины кроются в философии смысла. Каждый термин в языке является потенциальным объектом кластеризации, и каждый человек может иметь различное представление о том, что он означает. Поскольку отношения между субъектами скорее похожи на паутину, чем на дерево, даже те, кто согласен с паутиной, могут выбрать другое представление дерева. Это мои (часто повторяемые) общие замечания об опасностях иерархической классификации как общего решения.

Фактически, когда вы используете имя темы в URI, вы привязываете себя к некоей классификации. Возможно, в будущем предпочтёте иной вариант. Тогда URI будет подвержен нарушению.

Причина использования тематической области в качестве части URI заключается в том, что ответственность за подразделы пространства URI обычно делегируется, и тогда вам нужно имя организационного органа подразделения, группы или чего-то ещё, что несёт ответственность за это подпространство. Это привязка URI к организационной структуре. Обычно она безопасна только тогда, когда дальше (слева) URI защищён датой: 1998/pics может означать для вашего сервера то, что мы имели в виду в 1998 году под pics, а не то, что в 1998 году мы сделали с тем, что теперь называем pics.

Не забудьте доменное имя

Помните, что это относится не только к пути в URI, но и к имени сервера. Если у вас есть отдельные серверы для разных вещей, помните, что это разделение будет невозможно изменить, не уничтожив много-много ссылок. Некоторые классические ошибки типа посмотрите, какое программное обеспечение мы используем сегодня доменные имена "cgi.pathfinder.com", "secure", "lists.w3.org". Они созданы для того, чтобы облегчить администрирование серверов. Независимо от того, представляет ли домен какое-то подразделение в вашей компании, статус документа, уровень доступа или уровень безопасности, будьте очень, очень осторожны, прежде чем использовать более одного доменного имени для нескольких типов документов. Помните, что вы можете скрыть множество веб-серверов внутри одного видимого веб-сервера, используя перенаправление и проксирование.

Да, и ещё подумайте о своём доменном имени. Вы же не хотите, чтобы на вас ссылались как на мыло.ком после того, как вы смените продуктовую линейку и перестанете производить мыло (Прошу прощения у того, кто владеет soap.com в данный момент).

Заключение

Сохранение URI на 2, 20, 200 или даже 2000 лет, очевидно, не так просто, как кажется. Тем не менее, во всем интернете веб-мастера принимают решения, которые действительно затрудняют себе эту задачу в будущем. Часто это происходит потому, что они используют инструменты, задача которых заключается в том, чтобы представить лучший сайт только в данный момент и никто не оценил, что произойдёт со ссылками, когда всё изменится. Однако смысл здесь заключается в том, что многое, очень многое может измениться, и ваши URI могут и должны оставаться прежними. Это возможно только тогда, когда вы думаете о том, как вы их создаёте.

См. также:

• Тирада Якоба Нильсена на ту же тему

Дополнения

Как удалить расширения файлов...

из URI в текущем веб-сервере на основе файлов?

Если вы используете, например, Apache, то можете настроить его для согласования контента. Сохраняете расширение файла (например, .png) в файле (например, mydog.png), но ссылаться на веб-ресурс можно и без него. Затем Apache проверяет каталог на наличие всех файлов с этим именем и любым расширением, а также может выбрать лучший из набора (например, GIF и PNG). И не нужно помещать разные типы файлов в разные каталоги, на самом деле согласование содержимого не будет работать, если вы это сделаете.

• Настройте свой сервер на согласование контента
  
• Всегда делайте ссылки на URI без расширения

Ссылки с расширениями всё ещё будут работать, но не позволят вашему серверу выбрать лучший из доступных в настоящее время и будущих форматов.

(На самом деле, mydog, mydog.png и mydog.gif валидные веб-ресурсы, mydog это ресурс универсального контент-типа, а mydog.png и mydog.gif ресурсы конкретного контент-типа).

Конечно, если вы пишете собственный веб-сервер, то неплохо использовать базу данных для привязки постоянных идентификаторов к их текущей форме, хотя остерегайтесь неограниченного роста БД.

Доска позора История 1: Channel 7

В течение 1999 года я отслеживал закрытие школ из-за снега по странице http://www.whdh.com/stormforce/closings.shtml. Не ждать же, когда информация появится внизу экрана телевизора! Я поставил на неё ссылку со своей домашней страницы. Наступает первый большой снежный шторм 2000 года, и я проверяю страницу. Там написано:,

По состоянию на.
В настоящее время ничего не закрыто. Пожалуйста, возвращайтесь в случае погодных предупреждений.

Не может быть, такой же сильный шторм. Забавно, что дата отсутствует. Но если перейти на главную страницу сайта, там будет большая кнопка Закрытые школы, которая ведёт на страницу http://www.whdh.com/stormforce/ с длинным списком закрытых школ.

Может, они изменили систему получения списка но им не нужно было менять URI.

Доска позора История 2: Microsoft Netmeeting

С растущей зависимостью от интернета пришла умная мысль, что в приложения можно внедрять ссылки на сайт производителя. Этим часто пользовались и сильно злоупотребляли, но нельзя менять URL. Буквально на днях я попробовал ссылку из клиента Microsoft Netmeeting 2/something в меню Help/Microsoft on the Web/Free stuff получил ошибку 404 не найден ответ от сервера. Может, уже починили

1998 Tim BL

Историческое примечание: в конце 20-го века, когда это написано, круто было эпитетом одобрения, особенно среди молодёжи, указывающим на модность, качество или уместность. В спешке путь URI часто выбирали из крутости, а не полезности или долговечности. Эта заметка попытка перенаправить энергию, стоящую за поиском крутости.