Настройка Firefox помогла автору заметки возобновлять большие загрузки

Автор заметки обнаружил, что изменение network.http.response.timeout помогло ему возобновлять прерванные загрузки больших файлов в Firefox. Это экспериментальный совет, а продолжение скачивания зависит и от поддержки сервера.

· 4 мин чтения · 5 комментариев

Автор заметки «Making big downloads resumable in Firefox», опубликованной 12 октября 2026 года, описал настройку, которая в его опытах помогла продолжать прерванные загрузки больших файлов. Как он пишет, результат появился после изменения network.http.response.timeout в about:config. Это не сообщение о новой функции Firefox: автор проверял способ экспериментально и не обещает, что он поможет каждому. Кроме того, продолжение загрузки возможно, только если его поддерживает сервер.

Что меняет настройка тайм-аута

Автор заметки пишет, что начиная с Firefox 28 значение network.http.response.timeout по умолчанию — 300 секунд. Он предполагает, что этот тайм-аут мешает браузеру продолжать большие загрузки после ошибки и может сказываться на их устойчивости. Когда автор выставил 0 или очень большое число, в его опытах скачивание удавалось возобновить, а сам процесс стал немного стабильнее.

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

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

Почему одного файла .part недостаточно

Автор описывает случай, когда сервер допускает продолжение скачивания, а Firefox после ошибки всё равно не возобновляет его. По его наблюдениям, браузер может проигнорировать оставшийся от незавершённой загрузки файл .part. Поэтому само наличие такого файла не означает, что следующая попытка начнётся с места остановки.

Он предполагает, что поведение Firefox в этой ситуации связано с тайм-аутами соединения, а не просто с наличием .part. Это тоже не подтверждённый разбор работы браузера: автор прямо говорит, что не понимает причины. Его эксперимент показывает, какая настройка помогла ему, но не отвечает на все вопросы о возобновлении загрузок.

По словам автора, проблемы с их устойчивостью в Firefox встречались в обсуждениях ещё с 2005 года. Он нашёл и ручной способ работы с .part, однако сам им пользоваться не стал. Если нужен вариант вне браузера, автор приводит wget -c -O "$filename" "$url": в его опытах wget возобновлял скачивание и работал достаточно стабильно. Это альтернативный путь из заметки, а не гарантия результата для любого файла.

Что проверить на сайте с большими файлами

Для владельца сайта главное различие — между возможностью продолжить скачивание на стороне сервера и тем, воспользуется ли ею браузер после сбоя. Настройка Firefox относится только ко второй части. Если сервер не поддерживает возобновление, изменение тайм-аута не поможет ни в Firefox, ни в другом браузере.

Разработчику сервиса, где пользователи скачивают крупные материалы, я бы предложил проверять не только запуск загрузки, но и её поведение после прерывания. Сообщение «файл не продолжил скачиваться» само по себе не объясняет причину. В описанном автором случае сервер позволяет продолжить загрузку, однако Firefox после ошибки этого не делает — именно такую ситуацию помогла обойти настройка в его опытах.

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

Моё мнение: проверять весь путь скачивания

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

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

Источники

Откуда новость. Текст — пересказ своими словами, факты — из источника, мнение — автора.

  1. Making big downloads resumable in Firefox lunarwatcher.codeberg.page

Об авторе

Никола Иванов

начинающий full-stack-разработчик

Изучаю JavaScript и базы данных, собираю учебный магазин для знакомой, которая делает украшения. Мне интересно пройти весь путь заказа — от карточки товара до записи в базе — и понять, где я ошибся.

Все публикации автора

Скорость 4 мин чтения

Cloudflare открыла Origin Range Requests для кэширования частей больших файлов

Cloudflare представила Origin Range Requests для кэширования частей больших файлов. Функция доступна на всех тарифах, а после перехода R2 p99 времени до первого байта сократился примерно вдвое.

Бэкенд 4 мин чтения

Опубликованы детали предполагаемой уязвимости в обработке загрузок PHP

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

Бэкенд 3 мин чтения

В Go 1.27 улучшат повторное использование HTTP/1-соединений

В Go 1.27 пакет net/http.Transport будет асинхронно дочитывать непрочитанные тела ответов HTTP/1 — в пределах 256 КБ и 50 мс. Это поможет чаще повторно использовать соединения без дополнительного кода.

Написать комментарий

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

Без ссылок и рекламы. Первый комментарий публикуется после проверки. Отправляя комментарий, вы соглашаетесь с политикой конфиденциальности.

  1. У меня похожая история была с образами и архивами по несколько гигабайт: увеличение тайм-аута помогало пережить долгие паузы, но само по себе не гарантировало докачку. Если сервер не поддерживал Range-запросы или выдавал другой файл при повторном запросе, Firefox всё равно начинал заново. Поэтому я проверяю и настройку браузера, и заголовки ответа сервера — иначе легко принять временное улучшение за надёжный способ возобновления.

    1. @eto_dev, уточню: вы проверяете именно заголовок `Accept-Ranges: bytes` и что повторный запрос с `Range` возвращает тот же файл? По описанию настройка меняет тайм-аут ожидания ответа, так что без поддержки диапазонных запросов сервером она, похоже, может лишь помочь пережить паузу, но не обеспечить докачку.

      1. @karla.yanez, вы ещё смотрите, совпадает ли идентификатор файла при повторном запросе, например `ETag` или `Last-Modified`? Одного `Accept-Ranges: bytes` может быть мало, если за время паузы файл на сервере обновился: тогда докачка рискует склеить разные версии.

        1. Никола Иванов Автор публикации

          @ines.perf, хороший нюанс: если сервер отдаёт `ETag`, повторный Range-запрос можно сверять с ним через `If-Range`, а `Last-Modified` — запасной вариант, если стабильного ETag нет. Иначе действительно можно получить корректный ответ на диапазон, но склеить куски разных версий файла. Тайм-аут тут только даёт загрузке пережить паузу, а целостность всё равно зависит от сервера и проверки получившегося файла 🙂

      2. Никола Иванов Автор публикации

        Именно, я бы проверял обе вещи: `Accept-Ranges: bytes` — и что запрос с `Range` действительно возвращает нужный диапазон, а не просто заголовок для галочки. Ещё полезно сверить `ETag` через `If-Range` (или `Last-Modified`), чтобы при докачке не склеить части разных версий файла. Тайм-аут может помочь пережить долгий ответ или паузу, но сам механизм продолжения зависит от сервера 🙂