Перейти к содержимому
Все статьи
Поддержка

Докачка файла смешала версии: как проверить результат

23 октября 2026 г.· 7 мин чтения
Нужен тот, кто присмотрит за сайтом?Поддержка сайта
Старая последовательность AAAABBBB и смешанный результат AAAADDDD имеют по восемь байтов, но разное содержимое
Искусственные ASCII-последовательности для проверки; реальные документы не используются. Открыть схему крупнее

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

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

Восемь байтов, на которых видна ошибка

Пусть старая учебная версия содержит AAAABBBB, а новая — CCCCDDDD. Это последовательности из восьми ASCII-байтов. До обрыва сохранились первые четыре байта старой версии: AAAA. Если после замены ресурса загрузчик возьмёт последние четыре байта новой версии, получится AAAADDDD. Длина снова равна восьми, но это не старая и не новая версия.

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

Учебные пути возобновления загрузки
Сохранённое началоЧто получено затемРезультат склейкиВывод
AAAA из старой версииBBBB той же версииAAAABBBB, 8 байтовЧасти согласованы в примере
AAAA из старой версииDDDD новой версииAAAADDDD, 8 байтовРазмер совпал, содержимое смешано
AAAA из старой версииПолная новая версия CCCCDDDDAAAACCCCDDDD, 12 байтовПолное тело ошибочно дописано
Старую часть отбросилиПолная новая версия CCCCDDDDCCCCDDDD, 8 байтовПолучен новый целый учебный объект

Таблица не задаёт готовую реализацию загрузчика. Она отделяет продолжение от нового полного ответа. Для рабочего решения понадобятся проверка ответа сервера, правила временного хранения и наблюдаемое завершение. Нельзя переносить только операцию сложения массивов в приложение и считать задачу решённой.

Что означает условный запрос диапазона

HTTP позволяет запросить диапазон представления. If-Range связывает такую попытку с проверкой валидатора: при подходящем условии сервер может вернуть нужную часть, а при изменении представления — полное содержимое вместо продолжения. Это назначение описано в RFC 9110 и документации MDN. Для обсуждения исправления достаточно понять различие этих двух ветвей.

Вариант с ETag требует подходящего сильного валидатора; слабая метка с префиксом W/ для If-Range не используется. Не считайте любой встреченный заголовок готовым доказательством идентичности. Разработчик должен показать, какой валидатор получен, с каким ресурсом он связан и как именно применяется в используемом пути загрузки.

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

Загрузчик читает ответ, а не только своё намерение

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

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

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

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

Что сохранить вместе с временной частью

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

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

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

Один адрес может отдавать меняющееся содержимое

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

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

Имя документа решает другую задачу. Статья про имя скачиваемого файла рассматривает его передачу пользователю. Удобное название не является идентификатором содержимого, а исправление подписи сохранения не устраняет смешение версий. Эти проблемы полезно проверять отдельно даже тогда, когда жалоба сформулирована одинаково: «неправильный файл скачался».

Приёмка включает замену ресурса между запросами

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

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

Для итогового сравнения используйте известные учебные байты и независимый расчёт контрольной суммы там, где он предусмотрен. Не ограничивайтесь способностью редактора открыть документ: некоторые форматы допускают частичное чтение или не обнаруживают любую подмену. Критерий приёмки должен соответствовать согласованному объекту, а не только отсутствию сообщения об ошибке.

Что передать в задачу поддержки

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

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

Материалы для проверки

Если нужна реализация

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

Исправление выдачи и загрузки файлов Разработка кабинетов с файловым обменом

Связанный материал: Имя скачиваемого файла и заголовки ответа

Вопросы и ответы

Файл имеет правильный размер: значит, докачка исправна?

Нет. Учебный пример показывает смешение двух версий той же суммарной длины. Нужны согласованность частей и проверка ожидаемого содержимого.

Можно продолжать файл только по совпадающему имени?

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

Что делать, если на запрос продолжения пришёл полный ответ 200?

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

Нужно проверять ошибку на большом архиве клиента?

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

Нужна помощь с проектом?

Обсудим задачу и предложим решение — от сайта до SaaS и защиты.

Связаться