Почему веб-браузеры меняют файловые IRI?
Стандарт для файловых IRI ( https://tools.ietf.org/html/rfc8089) проводит различие между файловыми IRI без полномочий [1] и файловыми IRI с пустыми правами [2].
Современные веб-браузеры (протестированные на Firefox и Chrome) автоматически меняют [1] на [2]. Например, когда [1] появляется в теге ссылки, эффективная ссылка следует [2]. (Нет такого правила переписывания в документе RFC.)
[1] file:/C:/Program%20Files/Protege_2.1/2211#created_for
[2] file:///C:/Program%20Files/Protege_2.1/2211#created_for
Кто-нибудь знает, почему браузеры делают это и соответствует ли это стандартам?
Это приводит к реальным проблемам в настройках связанных данных, где [1] и [2] обозначают отдельные ресурсы.
1 ответ
Когда вы вводите примеры URI в браузере или нажимаете на них как на ссылку в веб-документе, браузер должен интерпретировать URI (который представлен в виде строки) как URL, чтобы найти ресурс. Именно на этом этапе интерпретации / перевода от входной строки (обозначающей действительный URI) к действительному URL-адресу один изменяется на другой. Чтобы проверить, действительно ли данная строка содержит действительный URL-адрес, строка интерпретируется конечным автоматом и преобразуется в представление URL-адреса в памяти. Этот конечный автомат имеет дело с различиями в представлении URI двух примеров, но приводит к одинаковому представлению URL в памяти. То есть в представлении в памяти не представлено никакой разницы между случаем отсутствия прав доступа и случаем пустых прав доступа. Затем представление URL в памяти сериализуется обратно в строку, которая является фактической строкой URL, как видно в браузере после ее ввода. Эта сериализация просто всегда добавляет двоеточие с двойным слешем:// к выходной строке, если схема представления в памяти - "файл".
Это поведение описано в стандарте URL-адреса WHATWG [1], см. Разбор URL-адресов (состояние файла) [2] и Сериализация URL-адреса [3].
Вопрос о том, является ли эта проблема сериализации следствием ужесточения требований к URL-адресам, а также к URI, вызывает у меня (также) интерес, однако в Приложении A к RFC 8089 говорится, что:
"Согласно определению в [RFC1738], URL файла всегда начинается с токена"file://", за которым следует (необязательно пустое) имя хоста и"/". Синтаксис, приведенный в Разделе 2, делает необязательным весь компонент полномочий, включая двойную косую черту "//".'
Поскольку это замечание явно говорит об URL, я интерпретирую это как компонент полномочий, который делается необязательным для URL (а не только более широкое определение URI) с помощью синтаксиса в Разделе 2 RFC 8089. Кажется, что стандарт URL WHATWG следует RFC1738 в этом аспекте. Он фактически считает два URL-адреса эквивалентными, когда проанализированная и повторно сериализованная выходные формы одинаковы, что имеет место в ваших примерах. Следовательно, кажется, что поведение не соответствует последним стандартам, RFC 8089 также предупреждает об этом.
[1] https://url.spec.whatwg.org/