Кратко

  • RFC 2397 определил data: для небольших «непосредственных» данных: необязательный медиатип, необязательный признак ;base64, запятая и сами данные.
  • Когда байты находятся в URL, контроль переходит от удалённого получения к локальному потребителю, политике медиатипов и границе буфера.

Обычный URL обещает путь: клиент читает местоположение, обращается к внешней системе и получает представление. RFC 2397 сократил эту цепочку. В data:[<mediatype>][;base64],<data> строка, обычно указывающая наружу, сама несёт то, что предстоит прочитать.

Документ назвал это «непосредственной адресацией». За запятой нет крошечного сервера. Для встроенного элемента потребитель отделяет объявление от нагрузки, восстанавливает октеты и толкует их по медиатипу. Указатель и груз становятся одним сериализованным входом.

Правила сокращения точны. При отсутствии типа используется text/plain;charset=US-ASCII; text/plain можно опустить, оставив charset. Признак ;base64 без знака равенства выбирает base64 и потому отличается от обычного параметра Content-Type. Без него безопасные символы URL прямо представляют октеты, остальные записываются как %xx. Base64 не шифрует, не подтверждает подлинность и не даёт разрешение.

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

RFC подчёркивает пригодность только для коротких значений. В качестве примера приведены пределы SGML в HTML 2.0: 1 024 символа для одного литерала атрибута, 2 100 для всех значений атрибутов тега и 2 100 для тега целиком. Даже небольшой GIF из примера назван близким к границе полезности. Это не универсальные пределы data:. Они показывают, что синтаксис, внешний контейнер и память допускают разные размеры.

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

Влияние очень длинных значений тогда оставалось неизвестным; программа могла вести себя неразумно, если вход превышал выделенный буфер. Здесь два самостоятельных вопроса: разрешён ли тип и можно ли безопасно обработать размер? Отсутствие внешнего запроса не отвечает ни на один.

Идея возникла в августе 1995 года. История RFC упоминает VRML, предложения по встраиванию данных в HTML, коммерческие продукты и параметры объектов Java и ActiveX. Формат уплотнялся: тип разрешили опускать, индикатор base64 сократили, а quoted-printable исключили, поскольку %xx уже выполнял нужную работу.

У errata различный статус. Два Verified исправляют невозможное %fg и заменяют отсутствующий в RFC 2396 термин urlchar на uric. Неясности с параметрами в кавычках и разделителями остаются Reported или Held for Document Update, а не утверждённым новым текстом. Предложение повсюду заменить «URL» на «URI» получило Rejected: исходное слово соответствовало времени публикации.

Главный урок RFC 2397 относится к контролю. Удаление посредника не уничтожает полномочия; оно сосредоточивает их в программе, которая разбирает, декодирует, интерпретирует и допускает. Чем короче путь, тем яснее должна быть локальная граница.

Источники