Interested Article - File (схема URI)

golda
  • 2021-06-16
  • 1

Схема URI file — это схема URI , документированная в , , и , предназначенная для того, чтобы адресовать файлы на локальном компьютере или в локальной сети, по их прямому пути на диске, в сетевой папке или, в отдельных случаях, на ftp-сервере. Схема URI file зарегистрирована в реестре схем URI IANA и входит в раздел «Перманентные схемы URI».

О схеме

Схема file является одной из старейших схем URI . Она была воплощена в программном обеспечении ещё на заре существования Интернета. WorldWideWeb , первый веб-браузер, созданный в 1991 г. Тимом Бернерсом-Ли , изобретателем Всемирной паутины , поддерживал схему file . Спецификация , в которой она была впервые документирована, была написана также Тимом Бернерсом-Ли в июне 1994 г., ещё до создания консорциума W3C , и является одной из старейших спецификаций Интернета.

До введения схемы ftp схема file использовалась для указания ссылок на файлы, находящиеся на ftp-серверах. Сам Тим Бернерс-Ли предложил использование схемы file в URL для ссылок на файлы, доступные по ftp-протоколу , и сам же применял такие ссылки в разделе «Список литературы» в своих публикациях . Браузер Lynx , один из старейших браузеров, доживший до наших дней, до нынешних дней сохранил такую интерпретацию схемы file .

В отличие от большинства известных схем (например, http, nfs, sip, telnet и т. д.), схема file не является протоколом. Об этом явно сказано в : «Особенностью этой схемы является то, что она не указывает интернет-протокол или метод доступа к файлу, поэтому её использование в сетевых протоколах между хостами ограничено» . Схема file просто указывает путь к файлу в виде URL (или URI) на одном конкретном компьютере. Там же сказано, что «эта схема, в отличие от большинства других схем URL, не определяет ресурс, который общедоступен через Интернет».

Схема file поддерживается всеми популярными браузерами, во всех операционных системах, хотя и базируется на очень старом стандарте, описывающем формат URL, а собственного пока не имеет. Но из-за указанных выше особенностей её использование ограничено. Она работает в адресной строке, но в HTML -разметке веб-сайтов эта схема практически не встречается. В настоящее время разработана новая схема app , которая должна прийти на замену file . Схема app описана в рекомендации W3C от 16 мая 2013 г.

Формат

URL со схемой file имеет формат : 

file://<host>/<path>

где host — это полное имя домена в системе, в которой доступен путь path , а path — это иерархический путь к каталогу, имеющий формат каталог / каталог /.../ имя_файла . Если host пропущен, используется значение по умолчанию «localhost», машина, на которой обрабатывается URL. До 2005 года в стандарте было требование, такое, что если хост опускается, то соответствующую косую черту или двойную косую черту опускать нельзя («file:///foo.txt» сработает, но «file://foo.txt» — нет, хотя некоторые парсеры способны были обрабатывать данный случай). , вышедшее в 2005 г., отменило это требование. Согласно , при опускании authority (в данном случае это эквивалент host ) опускается также и двойная косая черта (//).

Значение косой черты

Косая черта (/), в зависимости от позиции в URI, имеет разное значение.

  1. Двойная косая черта (//) после схемы file: — это часть синтаксиса URL , является обязательной при указании authority (поле host выступает в качестве authority).
  2. Косая черта между host и path — это также часть синтаксиса URL, хотя может являться составной частью path на Unix-системах или отсутствовать, если указанный путь относительный, т. е. начинается с «.» или «..».
  3. Остальные косые черты разделяют названия каталогов в поле path в иерархии каталогов локального компьютера. В данном случае косая черта — это независимый от системы способ отделения частей пути.

Другие компоненты URL

Компоненты логин (username), пароль (password) и порт (port) не используются в URL со схемой file. Но при этом могут использоваться компоненты параметры (query string) и якорь (fragment identifier) самим приложением, отображающим содержимое данного file URL. Например, скрипт внутри HTML -документа может прочитать параметры, а якорь может использоваться стандартным образом для навигации по документу.

Допустимые символы и их кодирование

File URL отличается по набору символов и от традиционных URL и от путей к файлу в файловых системах. Так как пути в файловых системах могут содержать символы, зарезервированные в URL для служебных целей ('#', '%' и др.), то такие символы (ранее также и пробел ' ') при конвертации пути в file URL кодируются . Но при этом, в отличие от URL, в file URL рекомендуется использовать символы иностранных алфавитов (то есть не из таблицы US-ASCII) как есть, то есть без URL-кодирования . Вызвано это тем, что URL-кодированные октеты в file URL рассматриваются как байты в текущей кодовой странице пользователя, то есть значение URL будет меняться в зависимости от локали, в которой просматривается документ .

Примеры

UNIX и UNIX-подобные операционные системы

4 примера на Unix , указывающие на один и тот же файл / etc / fstab : 

file://localhost/etc/fstab
file:///etc/fstab
file:///etc/./fstab
file:///etc/../etc/fstab

Пример ссылки на файл rfc959.txt, который находится на ftp-сервере nnsc.nsf.net : 

file://nnsc.nsf.net/rfc/rfc959.txt

Mac OS

2 примера на Mac OS , указывающие на один и тот же файл / var / log / system.log : 

file://localhost/var/log/system.log
file:///var/log/system.log

Windows

Примеры путей, поддерживаемых приложениями Windows , указывающие на файл c: \ WINDOWS \ clock.avi : 

file://localhost/c|/WINDOWS/clock.avi
file:///c|/WINDOWS/clock.avi
file://localhost/c:/WINDOWS/clock.avi
file:///c:/WINDOWS/clock.avi

Пример пути к файлу start.swf , расположенному в сетевой папке products на компьютере с сетевым именем applib : 

file://applib/products/a-b/abc_9/4148.920a/media/start.swf

Пример file URI с %-кодированными символами и с символом Unicode (в Internet Explorer 6-й и 7-й версии пример с %20 может не работать ): 

file:///C:/Documents%20and%20Settings/davris/FileSchemeURIs.doc
file:///C:/exampleㄓ.txt

Схема file и браузеры

Браузер Поддержка схемы file (localhost) Пустой host ( file:/// ) Сетевой host Буква диска в пути ( C: ) Обзор папок URL-кодированные символы file-ссылки в html
Google Chrome Да Да WINS Да Да Да Да
Internet Explorer Да Да WINS Да Нет Да Да
Konqueror Да Да ? - Да Да Да
Lynx Да Да FTP Да Да Да Да
Mozilla Firefox Да Да WINS Да Да Да Да
Opera Да Да WINS Да Да Да Да
Safari Да ? ? - Нет ? ?
Яндекс.Браузер Да Да WINS Да Да Да Да
Примечания к таблице
  1. Только для браузеров, поддерживающих Windows
  2. Обыкновенно заданный путь в виде file://hostname/share/path/to/a/file в Mozilla Firefox не работает, но можно задать его как file://///hostname/share/path/to/a/file . В 2001 г. Mozillа был заведен баг по этому поводу, несколько лет шло обсуждение, но его так и не стали исправлять (не нашли разумного решения)

Схема file в Windows

Схема URI file начала поддерживаться в Windows изначально, т.е. с появлением поддержки URI вообще, а конкретно — с выходом обозревателя Internet Explorer 1 . Первая версия Internet Explorer разрабатывалась в 1995 г., когда стандарта URL ещё не было, и схему file можно было трактовать по-разному, что и произошло с браузером. Разные его модули по-разному обрабатывали схему file. После переработки эта ситуация была устранена. Был создан shlwapi.dll , в который поместили весь код для работы с URL. В ходе переделки были согласованы две формы схемы file: одна по стандарту URL, другая — старая форма, пришедшая из времен DOS. Сотрудники Microsoft называли её legacy file URL (устаревший file URL). Примеры устаревших file URL: 

Путь к файлу:         c:\windows\My Documents 100%20\foo.txt 
Устаревший file URL:  file://c:\windows\My Documents 100%20\foo.txt 
Стандартный file URL: file:///c:/windows/My%20Documents%20100%2520/foo.txt

Путь к файлу:         \\server\share\My Documents 100%20\foo.txt 
Устаревший file URL:  file://\\server\share\My Documents 100%20\foo.txt
Стандартный file URL: file://server/share/My%20Documents%20100%2520/foo.txt

Новая dll умеет правильно обрабатывать и новые, и старые file URL, поэтому её функции PathCreateFromUrl() и UrlCreateFromPath() рекомендуется использовать для конвертации между путями Windows и file URL .

Кроме данных функций, была создана функция CreateURLMoniker() в urlmon.dll (начиная с Internet Explorer 3 ), предназначенная для того, чтобы сконвертировать строковый URI в объект, с помощью которого можно получить данные, адресованные данным URI ( ). Но и эта функция вызывала некоторые проблемы с конвертацией file URI , в результате чего была добавлена и рекомендована для использования новая функция CreateURLMonikerEx() (начиная с Internet Explorer 5.5 ), в которой все эти проблемы были исправлены. С выходом Internet Explorer 7 была добавлена ещё одна функция CreateURLMonikerEx2(), которая поддерживает относительные пути.

Проблемы безопасности

С появлением и распространением в браузерах поддержки скриптовых языков , таких, как JavaScript , был обнаружен ряд уязвимостей, связанных с использованием схемы file. В связи с этим разработчики браузеров ввели ряд встроенных ограничений в браузерах на использование file URL.

Основные уязвимости браузеров, связанные с file URI

Ссылки со схемой file в документах HTML, загруженных по протоколу HTTP, не работают практически во всех популярных браузерах: Internet Explorer (начиная с версии 6 SP1) , Mozilla Firefox , Chromium и Google Chrome , Safari [ источник не указан 3778 дней ] , Opera [ источник не указан 3778 дней ] . При нажатии на такие ссылки не происходит ни навигации, ни показа сообщения об ошибке, хотя сообщение об ошибке может быть записано в консоли ошибок. Также контент по ссылке file URL не загружается во фреймы документа HTML, загруженного по HTTP URL. Такая политика безопасности была введена в связи с тем, что такие ссылки вызывают ряд уязвимостей:

  • HTML-документ, размещенный на сайте злоумышленника, может подгрузить файлы на компьютере пользователя при помощи ссылок file URL, и затем отправить их на сервер, находящийся под контролем этого злоумышленника. Злоумышленник получает доступ к конфиденциальным данным пользователя;
  • Многие браузеры и плагины к ним держат свои временные файлы и кэш в предсказуемых местах на диске. Атакующий может вначале разместить файл HTML в одном из этих мест во время обычной работы браузера (злоумышленник на контролируемом сайте может попросить сохранить веб-страницу на диск или прислать её в архиве на электронную почту), и затем попробовать открыть его, вызвав через специально подготовленный file URL. HTML-документ, открытый локально (через file URL), имеет больше привилегий, чем удалённый, и может как получить доступ к конфиденциальным данным пользователя, так и совершать другие нежелательные действия. Этот метод атаки также называют «file-URL-to-file-URL scripting» . Кроме того, пользователь может сам открыть вредный html-документ локально у себя на компьютере.
  • Локально открытый html-файл может загрузить удалённую веб-страницу в iframe (так как локальные файлы на компьютере не подпадают под Правило ограничения домена , действующее только для сайтов), например, сайт электронной почты, где пользователь уже залогинен, и получить таким образом доступ к конфиденциальным данным пользователя, находящимся в интернете.

Для борьбы со второй уязвимостью была также введена политика под названием « Правило ограничения домена » ( same origin policy ), аналогичная одноимённой политике, введённой ранее для сайтов http-зоны. Mozilla Firefox, который ввёл эту политику в версии браузера 3 (движок Gecko 1.9) в 2007 г., был в этом одним из первых (на обсуждение и реализацию этой политики у разработчиков Firefox ушло 3 года ). Согласно этому правилу, файл может читать другой файл, только если родительский каталог исходного файла является надкаталогом для целевого файла . Microsoft ранее поступил жёстче и вообще отключил исполнение Javascript при открытии любых локальных файлов, начиная с Internet Explorer 6 в Windows XP SP2, добавив пользователям возможность выполнить сценарий выбором специальной команды во всплывающем меню. Safari 3.2 не даёт пользователю возможности открыть локальные file URL из каких-либо других источников, кроме как из адресной строки. Opera 9.6 не позволяет локальным html-страницам загружать удалённый контент (но это не защищает от возможности доступа злоумышленника к данным на компьютере). Chromium (и зависящий от него Google Chrome) реализовал политику, аналогичную политике Opera и взял также на рассмотрение политику Firefox, но позже реализовал ещё более жёсткую политику , запретив обращения к file URL для скриптов в локальных веб-страницах вообще (позже было решено ослабить эту политику).

В результате ввода таких ограничений появилось много жалоб, так как это препятствовало работе локальных сайтов и веб-справочников, которые широко применяются во многих корпоративных и локальных сетях, в дистрибутивах на CD, в приложениях к электронной почте, а также используются веб-разработчиками для отладки сайтов. Например, в Mozilla по этому поводу было заведено несколько десятков багов-дубликатов . Поэтому в браузерах была поддержана возможность обхода, отключения или конфигурирования этой политики, а также появились статьи, подсказывающие, как это сделать. Так, в Internet Explorer эта политика настраивается параметром «Websites in less privileged web content zone can navigate into this zone» " в настройках зоны «My computer» или другой. Также этот запрет обходится добавлением веб-сайтов, не вызывающих никаких опасений, в зону «Надежные узлы» Internet Explorer [ источник не указан 3778 дней ] . В Mozilla Firefox этот запрет обходится с помощью расширений LocalLink, Local Filesystem Links, IE Tab; или специальной настройкой политики безопасности (для группы сайтов создаётся специальная зона со своими специфическими настройками безопасности) . В Google Chrome начиная с версии 7 этот запрет можно обойти, запустив браузер с флагом --allow-file-access-from-files или используя расширение LocalLinks. В Chromium также, как следствие многочисленных жалоб, решили ослабить политику « Правило ограничения домена » для file URL .

Ограничения политики безопасности в браузерах

Основные ограничения политики безопасности в браузерах отражены в таблице .

Описание теста MSIE6 MSIE7 MSIE8 FF2 FF3 Safari Opera Chrome
Имеют ли локальные HTML доступ к несвязанным локальным файлам через DOM? Да Да Да Да Нет Нет Да Нет
Имеют ли локальные HTML доступ к несвязанным локальным файлам через XMLHttpRequest? Нет Нет Нет Да Нет Нет Да Нет
Имеют ли локальные HTML доступ к сайтам в Интернет через XMLHttpRequest? Да Да Да Нет Нет Нет Нет Нет
Работает ли document.cookie с file URL? Да Да Да Да Да Да Да Нет
Разрешается ли загружать тег <IMG> с file URI? Да Да Да Нет Нет Нет Нет Нет
Разрешается ли загружать тег <SCRIPT> с file URI? Да Да Да Нет Нет Нет Нет Нет
Разрешается ли загружать тег <IFRAME> с file URI? Да Да Да Нет Нет Нет Нет Нет
Разрешается ли загружать тег <EMBED> с file URI? Нет Нет Нет Нет Нет Нет Нет Нет
Разрешается ли загружать тег <APPLET> с file URI? Да Да Да Нет Нет Да Нет Да
Можно ли загружать стили (stylesheet) через file URI? Да Да Да Нет Нет Нет Нет Нет
Разрешены ли редиректы (Location redirection) через file URI? Нет Нет Нет Нет Нет Нет Нет Нет
Разрешены ли редиректы (Refresh redirection) через file URI? Нет Нет Нет Нет Нет Нет Нет Нет
Примечания к таблице
  1. Данные таблицы, для всех браузеров, если это не указано отдельно, взяты из работы Михала Залевски «Browser Security Handbook» , основной материал которой был написан ещё в 2008 году , и могут быть неактуальны для более новых версий браузеров
  2. MSIE6 - Microsoft Internet Explorer 6 (v6.0.2900.5512)
  3. MSIE7 - Microsoft Internet Explorer 7 (v7.0.5730.11)
  4. MSIE8 - Microsoft Internet Explorer 8 (v8.0.6001.18702)
  5. FF2 - Mozilla Firefox 2 (v2.0.0.18)
  6. FF3 - Mozilla Firefox 3 (v3.6.8)
  7. Safari - Apple Safari v4.0
  8. Opera - Opera v9.62
  9. Chrome - Google Chrome v7.0.503.0

Атака XXE

Атака XXE ( англ. Xml eXternal Entity ) — одна из известнейших уязвимостей в Интернете. Этот класс уязвимостей зарегистрирован в крупнейших каталогах уязвимостей: и . Суть атаки в следующем. Есть сервисы, поддерживающие протоколы SOAP и XML-RPC , которые принимают входные данные в виде XML -документа. Стандарт XML-документа поддерживает включение секции DTD , а секции DTD, в свою очередь, могут подключать к документу дополнительные компоненты, так называемые внешние сущности ( англ. external entity ) . Внешние сущности являются отдельными файлами и задаются с помощью ключевого слова SYSTEM и URI. Если XML-парсер невалидирующий, он может просто загрузить внешнюю сущность и подключить к содержимому XML-документа. Злоумышленник может подставить в URI внешней сущности file URI, указывающий на аппаратное устройство ЭВМ или на локальный файл в системе. Сервер попытается прочитать файл по указанному URI и включить его содержимое в XML. При использовании такого механизма возможны следующие виды атак :

  • DoS-атака (отказ в обслуживании) сервера, посредством обращения к устройству системы, такому, как /dev/urandom или;
  • получение несанкционированного доступа к закрытым файлам сервера, например, /etc/passwd или c:/winnt/win.ini ;
  • сканирование TCP-портов (даже в обход фаервола);
  • DoS-атака других систем (если парсер позволяет устанавливать TCP-соединения в другие системы)
  • кража материалов NTLM-аутентификации, инициированная через UNC -обращение к системе, находящейся под контролем злоумышленника;
  • сценарий «судный день»: широко развернутое и имеющее большое количество подключений серверное приложение, подверженное этой уязвимости, может использоваться для DDoS-атаки (распределённый отказ от обслуживания).

Уязвимость XXE в сообществе (сайт некоммерческой организации OWASP ) начали обсуждать ещё с 2001 года , но это были лишь теоретические размышления о возможности атаки такого вида. Первый, кто обратил внимание общественности на эту уязвимость, был Грегори Стейк ( англ. Gregory Steuck ) . В 2002 году он отправил security advisory (инструкция по безопасности) на www.securityfocus.com , в котором подробно описал уязвимость и дал ей название атака XXE ( англ. XXE Attack ).

Атаке XXE были подвержены многие продукты. Во всех крупнейших базах данных уязвимостей программного обеспечения можно найти программные продукты, уязвимые для атак XXE: в , в Common Vulnerabilities and Exposures , в . Уязвимость для «атак XXE» была обнаружена в таких известных продуктах, как JDK и JRE (6-я версия, 3-е обновление) , WebKit и сделанный на его основе браузер Safari (3-я версия) , Spring Framework , CakePHP , Adobe Reader (7-я версия) , Zend Framework , и др.

Стандартизация и спецификации

Схема URI file впервые была описана в июне 1994 г. в информационном («Universal Resource Identifiers in WWW»). В декабре того же года она была стандартизирована в (Uniform Resource Locators (URL)). описывает общий формат URL и на данный момент уже является устаревшим, за исключением двух секций, в которых описываются схемы file и ftp. Новый (Uniform Resource Identifier (URI): Generic Syntax), вышедший в 2005, вобрал в себя , внёс небольшие изменения, но он не описывал отдельные схемы. К тому времени почти все схемы из раздела перманентных получили свой собственный отдельный стандарт. Старый лишь утверждал формат схемы, но не определял правил по применению этой схемы и конвертации локального пути в URI и обратно. Назревала необходимость стандартизировать схему file, а также ряд других нестандартизированных схем.

В 2004 г. Пол Хоффман, являющийся участником IETF ещё с ранних 1990-х, начал процесс стандартизации схемы file. В течение июня он написал отдельные спецификации для схем file, ftp, gopher, news и nntp, prospero и telnet, и 17 июня 2004 они были опубликованы на сайте ietf.org, а 19 июня он объявил об этом в списке рассылки . Первая ревизия стандарта схемы file имела название «The file URI Scheme» . 19 июня Пол Хоффман объявил о Началось активное обсуждение черновика. Сообщество IETF высказало много замечаний, и вскоре вышла вторая ревизия , потом третья и четвертая . Но консенсус так и не был достигнут. Для продолжения работы над стандартом Майк Браун создал специальный вики -сайт , где некоторое время велась работа по сбору информации, касающейся схемы file. Но вскоре эта деятельность затихла, а стандарт так и не был принят.

В 2013 г. Мэтью Кервин делает новую попытку стандартизировать схему file. В июне 2013 была опубликована первая ревизия черновика , началось обсуждение черновика, и в течение июня-сентября вышло ещё 8 ревизий. Последняя (№8, т.е. девятая ) ревизия черновика была опубликована 18 сентября 2013

Примечания

Комментарии
  1. Этот пример работает только в браузере Lynx
  2. Термин URI появился позже, на тот момент его прототипом был URL, здесь и далее в статье под URI может подразумеваться URL
  3. Ссылки со схемой file с нелокальным хостом (т. е. URL, указывающие на UNC -путь, например, file://dmitryt/public/readme.txt ), работали в Internet Explorer вплоть до 9-й версии, но в обновлении до версии 9.02, вышедшем в августе 2011 года, эта возможность была отключена
  4. Черновики стандартов IETF нумеруются с 0
Источники
  1. от 11 октября 2016 на Wayback Machine (англ.) (iana.org)
  2. Tim Berners-Lee, et. al. (англ.) // New Computing Techniques in Physics Research. — Singapore: World Scientific. — P. 157—164 . 24 сентября 2015 года.
  3. (англ.) . Lynx User's Guide . июля 2009). Дата обращения: 9 октября 2013. (недоступная ссылка)
  4. ↑ T. Berners-Lee, L. Masinter, M. McCahill. (англ.) . Request for Comments: 1738 14. IETF (декабрь 1994). Дата обращения: 6 октября 2013. 15 октября 2013 года.
  5. Marcos Cáceres. (англ.) . W3C (16 мая 2013). Дата обращения: 8 октября 2013. 6 октября 2013 года.
  6. ↑ Dave Risney. (англ.) . MSDN (6 декабря 2006). Дата обращения: 16 октября 2013. 4 августа 2013 года.
  7. ↑ Risney, Dave (англ.) . IEBlog . Microsoft Corporation (2013). Дата обращения: 7 августа 2013. 4 августа 2013 года.
  8. (англ.) . Microsoft (26 октября 2007). Дата обращения: 20 октября 2013. 16 января 2006 года.
  9. от 21 октября 2013 на Wayback Machine . (2001-03-04). Mozilla
  10. Zeke Odins-Lucas. (англ.) . MSDN (19 мая 2005). Дата обращения: 15 октября 2013. 16 января 2013 года.
  11. ↑ Dave Risney. (англ.) . MSDN (14 сентября 2006). Дата обращения: 16 октября 2013. 17 октября 2013 года.
  12. (англ.) . MSDN . Дата обращения: 20 октября 2013. 4 мая 2016 года.
  13. Eric Law. (англ.) . MSDN (12 августа 2011). Дата обращения: 19 октября 2013. 20 октября 2013 года.
  14. ↑ (англ.) . MozillaZine Knowledge Base . Mozilla . Дата обращения: 19 октября 2013. 20 октября 2013 года.
  15. ↑ . Bugzilla@Mozilla . Mozilla (26 января 2002). Дата обращения: 20 октября 2013. 24 октября 2013 года.
  16. A. Barth, C. Jackson, C. Reis, and Google Chrome Team. (англ.) : Technical report. — Stanford University, 2008. — P. 6 . 7 сентября 2011 года.
  17. Šilić, M. ; Krolo, J. ; Delac, G. (англ.) // MIPRO, 2010 Proceedings of the 33rd International Convention. — Opatija, Croatia, 2010. — P. 1240—1245 . — ISBN 978-1-4244-7763-0 . 23 февраля 2024 года.
  18. (англ.) . Common Vulnerabilities and Exposures (29 мая 2009). Дата обращения: 19 октября 2013. 2 апреля 2015 года.
  19. . Bugzilla@Mozilla . Mozilla (10 января 2004). Дата обращения: 20 октября 2013. 25 апреля 2014 года.
  20. (англ.) . . Дата обращения: 20 октября 2013. Архивировано из 16 августа 2013 года.
  21. Adam Barth. (англ.) . Chromium (4 декабря 2008). Дата обращения: 20 октября 2013. 27 октября 2013 года.
  22. (англ.) . Google . Дата обращения: 20 октября 2013. 24 октября 2013 года.
  23. (англ.) . Google . Дата обращения: 20 октября 2013. 24 октября 2013 года.
  24. Michal Zalewski. (англ.) . Google (10 декабря 2008). Дата обращения: 20 октября 2013. 19 августа 2016 года.
  25. Michal Zalewski. (англ.) . Google Online Security Blog (10 декабря 2008). Дата обращения: 20 октября 2013. 25 апреля 2014 года.
  26. (англ.) . Дата обращения: 7 ноября 2013. 30 марта 2020 года.
  27. (англ.) . Дата обращения: 7 ноября 2013. 5 декабря 2013 года.
  28. Эллиот Расти Гарольд, В. Скотт Минс. = XML in a Nutshell, Second Edition / Пер. с англ.. — СПб. : Символ-Плюс, 2002. — С. -80. — 576 с. — ISBN 5-93286-025-1 .
  29. ↑ Steuck, Gregory (англ.) . www.securityfocus.com (29 октября 2002). Дата обращения: 25 октября 2013. 29 октября 2013 года.
  30. Wilson, John (01 Jan 2001). . XML-DEV (Mailing list) (англ.) . из оригинала 29 октября 2013 . Дата обращения: 12 октября 2013 . {{ cite mailing list }} : Проверьте значение даты: |date= ( справка )
  31. Sabin, Miles (30 Oct 2002). . XML-DEV (Mailing list) (англ.) . из оригинала 29 октября 2013 . Дата обращения: 12 октября 2013 .
  32. (англ.) . Дата обращения: 7 ноября 2013. 2 июня 2013 года.
  33. ↑ (англ.) . Дата обращения: 7 ноября 2013. 4 марта 2016 года.
  34. (англ.) . Дата обращения: 7 ноября 2013. (недоступная ссылка)
  35. Chris Evans. (англ.) . обращения: 7 ноября 2013. 10 января 2013 года.
  36. Дмитрий Докучаев. // Хакер . — 2009. — Вып. 127 , № 07 . — С. 44-50 . 25 апреля 2014 года.
  37. (англ.) . www.securityfocus.com (9 июня 2009). Дата обращения: 7 ноября 2013. 4 марта 2016 года.
  38. (англ.) . www.securityfocus.com (22 августа 2013). Дата обращения: 7 ноября 2013. 7 сентября 2013 года.
  39. (англ.) . securityfocus.com (16 июля 2012). Дата обращения: 7 ноября 2013. 10 октября 2012 года.
  40. Sverre H. Huseby. (англ.) . securityfocus.com (16 июня 2005). Дата обращения: 7 ноября 2013. 4 марта 2016 года.
  41. (англ.) . www.securityfocus.com (26 июня 2012). Дата обращения: 7 ноября 2013. 7 июля 2012 года.
  42. (англ.) . securityfocus.com (18 июня 2012). Дата обращения: 7 ноября 2013. 4 марта 2016 года.
  43. Hoffman, Paul (19 Aug 2004). . [email protected] (Mailing list) (англ.) . из оригинала 11 июня 2015 . Дата обращения: 26 сентября 2013 .
  44. P. Hoffman. (англ.) . IETF (17 августа 2004). Дата обращения: 6 октября 2013. 13 сентября 2014 года.
  45. P. Hoffman. (англ.) . IETF (18 сентября 2004). Дата обращения: 6 октября 2013. 13 сентября 2014 года.
  46. P. Hoffman. (англ.) . IETF (30 ноября 2004). Дата обращения: 6 октября 2013. 13 сентября 2014 года.
  47. P. Hoffman. (англ.) . IETF (январь 2005). Дата обращения: 6 октября 2013. 24 июля 2014 года.
  48. M. Kerwin. (англ.) . IETF (20 июня 2013). Дата обращения: 6 октября 2013. 4 февраля 2015 года.
  49. M. Kerwin. (англ.) . IETF (18 сентября 2013). Дата обращения: 6 октября 2013. 4 февраля 2015 года.

См. также

Ссылки

  • - вики-сайт для сбора информации о схеме file и координации работ по стандартизации схемы file
  • - статья об использовании URI со схемой file в Windows API
  • - о формате URI со схемой file в Windows 7
  • — статья об использовании URI со схемой file на языке Java
  • - использование URI со схемой file на языке Perl
Источник —

golda
  • 2021-06-16
  • 1
  • Tags:

Same as File (схема URI)

The title for the last searches