Я использую nginx 1.2.3 для прокси к скрипту:
proxy_set_header Host $host;
proxy_pass http://127.0.0.1:8880;
proxy_buffering off;
proxy_read_timeout 300s;
gzip off;
Скрипты отправляют как Transfer-encoding: chunked
и Content-Length: 251
:
HTTP/1.0 307 Temporary Redirect
Content-length: 251
Pragma: no-cache
Location: /...
Cache-control: no-cache
Transfer-encoding: chunked
Мне нужны оба, но nginx автоматически удаляет Content-Length
:
HTTP/1.1 302 Found
Server: nginx/1.2.3
Content-Type: application/json; charset=utf-8
Content-Length: 58
Connection: keep-alive
Location: /...
В результате клиенты не ждут отправки чанков. Раньше это работало с более ранней версией nginx.
Ответы:
К сожалению, я не могу комментировать сообщение cnst - поэтому я собираюсь ответить здесь.
nginx_http_proxy
Модуль по умолчанию переговоров с верховьями в HTTP / 1.0. Это можно изменить с помощью директивыproxy_http_version 1.1
.Это также может быть причиной того, что ваш сценарий возвращает ответ HTTP / 1.0, хотя чанкованное кодирование и код состояния
307
не существуют в этой версии.Вы не должны использовать чанкованное кодирование с перенаправлением , так как это не имеет смысла.
Кроме того , кажется, что nginx не передает порции от вышестоящего к клиенту один за другим, но буферизует ответ вышестоящего . Поле
Content-Length
заголовка игнорируется, поскольку оно противоречит определению. Мне пришлось посмотреть на исходный код модуля, потому что все это выглядит недокументированным.Возможно, вы захотите попробовать
nginx_tcp_proxy_module
проксировать содержимое в виде сырых данных TCP: Модуль на GithubОБНОВЛЕНИЕ (10.04.14) модуль имеет поддержку для заголовков , один из которых ( ) определяет , будет ли ответ должен быть буферизованными или нет.
nginx_http_proxy
X-Accel-*
X-Accel-Buffering: yes|no
Добавление этого заголовка (
X-Accel-Buffering: no
) к ответу бэкэнда заставит nginx напрямую передавать чанки клиенту.Этот заголовок позволяет контролировать буферизацию для каждого запроса .
Модуль также имеет директиву конфигурации
proxy_buffering
для включения или отключения буферизации ответов (не буферизация означает, что отправка чанков будет работать).Прокси - буферизация (как заголовок и директива основе) документирован здесь .
источник
nginx_tcp_proxy_module
. Он работает с некоторыми браузерами только потому, что они очень устойчивы к ошибкам.Как намекает Лукас, HTTP 1.1 запрещает
Content-Length
наличиеTransfer-Encoding
набора.Цитирование http://www.ietf.org/rfc/rfc2616.txt :
источник
Вы специально не выяснили, почему вашему сценарию нужно в первую очередь частичное кодирование, особенно с ответом на перенаправление.
Я вижу множество проблем здесь.
Transfer-Encoding: chunked
этоHTTP/1.1
особенность (и ваш скрипт, кажется, отвечает сHTTP/1.0
заголовком)нет
307
вHTTP/1.0
вся цель в
chunked
том, что вы не знаете, чемContent-Length
бы вы были, поэтомуchunked
используется вместо предоставления длины внутриContent-Length
, где вместо этого длины предоставляются в теле ответа, смешанного с фактическим содержанием; для сценария было бы бессмысленно генерировать оба заголовка заранееЯ лично не знаком с
chunked
, но согласно основной информации на http://en.wikipedia.org/wiki/Chunked_transfer_encoding, а также http://tools.ietf.org/html/rfc2616#section-3.6.1 , Я бы предположил, что вся обработка вашего скрипта кусковой кодировки может быть полностью неверной.Если вышеупомянутое все еще не покрывает это, и во всей действительности иначе, также неясно, почему ответ с кодом состояния
307
или302
http должен быть снабжен "странной" кодировкой. Недавно в списке рассылки nginx было похожее обсуждение,410 Gone
и другие страницы с ошибками всегда исключались изgzip
сжатия, и я думаю, что мнение будет в равной степени применимо и здесь. ( http://mailman.nginx.org/pipermail/nginx/2013-March/037890.html )источник
У меня была та же самая проблема потокового файла mp4 через тег видео html5.
Safari и Firefox вели себя нормально, в то время как Chrome в какой-то момент запускал ERR_CONTENT_LENGTH_MISMATCH (но это позволило мне просмотреть несколько минут видео перед тем, как его потерпеть неудачу).
Проблема не воспроизводилась после того, как я отключил управление кэшем для файлов mp4.
источник
Делясь этим ответом, я отправил сообщение SO на случай, если это будет полезно: /programming/50499637/mp4-video-safari-cloudflare-nginx-rails-no-play/59348509#59348509
У меня была похожая проблема с воспроизведением mp4 из-за того, что куски не обслуживались, и я подтвердил проблему в соответствии с руководством Apple, перечисленным ниже. Я подтвердил, что загружаю весь файл, и после исправления ниже только первый чанк.
Я разрешил воспроизведение Safari .mp4, изменив настройки сжатия gzip в файле nginx.conf, чтобы удалить сжатие gzip файлов .mp4 .
Вот блок в nginx для справки. (Примечание: в зависимости от того, как настроено ваше приложение, может потребоваться изменить строку местоположения на
location ~ \.mp4$ {
Ссылка на справочную документацию Apple: https://developer.apple.com/library/archive/documentation/AppleApplications/Reference/SafariWebContent/CreatingVideoforSafarioniPhone/CreatingVideoforSafarioniPhone.html#//apple_ref/doc/uid-TP665
источник