Русский

Видео и субтитры · Загрузчик медиафайлов по прямой ссылке

Анатомия URL: почему адрес страницы не является адресом загружаемого файла

· Фон

URL-адреса загрузки веб-основы

URL разделен на блоки схемы, хоста, пути, запроса и фрагмента.
Оригинальная векторная иллюстрация ToolAcre

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

По ссылке из адресной строки ничего не скачивалось — путаница где живет страница и где живет файл

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

Адрес загружаемого файла — это ресурс HTTP, телом ответа которого является целевой файл. URL внешний вид может указывать на такую ​​связь, но не может установить ее без доказательств контакта и реакции. Поэтому полезный первый вопрос: «Похоже ли это на видео?» но «какой ресурс, по словам издателя, представляет этот точный адрес?» Начните с вопроса, какой ресурс издатель намеревался представлять в этом скопированном адресе, а не с того, появляется ли где-то внутри него знакомое слово.

Схема и хост — https, домен и почему хост — это та часть, которую инструмент объявляет перед обращением к нему.

В `https://cdn.example:8443/archive/cut.mp4` HTTPS — это схема, cdn.example — имя хоста, а 8443 — явный порт. Происхождение объединяет эти компоненты.

Direct Media Downloader принимает только HTTPS и объявляет нормализованное имя хоста перед контактом. Он отклоняет учетные данные, встроенные перед хостом и известными частными или внутренними пунктами назначения, включая запутанные формы адреса. Явный порт, отличный от порта по умолчанию, может идентифицировать отдельную службу, поэтому не опускайте его мысленно только потому, что в объявлении пользовательского интерфейса выделяется имя хоста. Явный порт остается частью источника и может идентифицировать отдельную службу, даже если в коротком объявлении подчеркивается имя хоста.

Путь — папки и последний сегмент, где обычно появляются имя и расширение файла.

Путь начинается после авторитета и разделяется косой чертой. Его последний сегмент часто напоминает имя файла, которое ToolAcre может использовать, если Content-Disposition не предлагает лучшего предложения.

«Часто» не является доказательством. `/watch/abc`, `/download/42` и `/asset.mp4` — это маршруты, определяемые сервером. Любой может вернуть HTML, носитель, ошибку или перенаправление в зависимости от поведения хоста. Символы с процентной кодировкой также могут изменить видимый путь после декодирования, что делает анализируемое представление браузера более безопасным для проверки, чем случайное разделение строк. Процентное кодирование может привести к тому, что отображаемый конечный сегмент будет отличаться после декодирования, что является еще одной причиной использования структурированного анализа вместо разделения по косой черте.

Запрос и фрагмент — параметры, токены и привязки, и почему запрос ?v=ID не указывает на видеофайл

Запрос начинается со знака вопроса и может выбрать ресурс, авторизовать подписанную ссылку или провести аналитику. Фрагмент начинается с `#` и обычно выбирает состояние документа на стороне клиента, а не отправляется в запросе HTTP.

Такой параметр, как `v=ID`, обычно определяет состояние страницы; это само по себе не означает, что ответом является видеофайл. ToolAcre сохраняет несущие сигнатуры, удаляя при этом консервативный список значений отслеживания во время нормализации. Фрагменты по-прежнему могут влиять на то, что страница отображает после навигации, поэтому копия адресной строки может сохранять состояние интерфейса, не связанное с ответом сервера. Фрагменты могут по-прежнему изменять состояние страницы на стороне клиента после навигации, несмотря на то, что они отсутствуют в запросе, отправленном на сервер.

Как определить вероятную прямую ссылку на файл — расширение, отсутствие страницы проигрывателя и хост, который обслуживает файлы, а не страницы

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

Проверьте ссылку, чтобы затем запросить заголовки. Тип медиа-контента поддерживает эту гипотезу, а `text/html` выдает предупреждение. Ответ все еще может быть неправильно помечен, поэтому успешная загрузка и воспроизведение остаются последующими наблюдениями. Кнопка загрузки на собственной странице издателя является более убедительным доказательством предполагаемого извлечения, чем запросы на реверс-инжиниринг, отправленные только для воспроизведения. Официальные инструкции по загрузке от издателя обеспечивают более надежный контекст, чем реверс-инжиниринг ресурса, наблюдаемого только во время защищенного воспроизведения.

Проработанный пример: анализ пяти форм ссылок — файла CDN, сокращателя, страницы просмотра, подписанного URL и страницы с фрагментом.

Сравните пять фигур: путь CDN, заканчивающийся `.mp4`; короткая ссылка, которая перенаправляет; страница просмотра с запросом идентификатора; путь хранения с подписью и сроком действия; и фрагмент документа.

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

Чего это не касается: URL сам по себе не может доказать существование файла или его тип на самом деле.

Анализ URL не может доказать существование, тип контента, длину, авторизацию, безопасность или юридическое разрешение. Он также не может предсказать места назначения перенаправления без запроса.

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

Вывод: прочитайте ссылку, прежде чем вставлять ее — как проверка URL Direct Media Downloader делает то же самое для вас.

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

Direct Media Downloader применяет это структурное чтение локально, а затем ожидает действия. Его необязательный запрос HEAD и последующий GET отвечают на различные вопросы, на которые не может ответить один только синтаксис. Такое многоуровневое чтение предотвращает как ложные срабатывания, так и ложные гарантии, сохраняя при этом полезную информацию о подписанных запросах, необходимую законным системам доставки. Этот многоуровневый метод сохраняет законные подписанные параметры, предотвращая при этом визуальное восприятие, которое можно ошибочно принять за авторизацию или существование.