Opened 7 years ago
Closed 7 years ago
#1290 closed defect (invalid)
проблема с proxy_store при использовании https
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | major | Milestone: | |
Component: | other | Version: | 1.11.x |
Keywords: | Cc: | ||
uname -a: |
# uname -a
FreeBSD dll.domain.tld 12.0-CURRENT FreeBSD 12.0-CURRENT #1 r319492: Sat Jun 3 15:06:34 UTC 2017 tiger@dll.domain.tld:/usr/obj/usr/src/sys/GENERIC-NODEBUG amd64 |
||
nginx -V: |
# nginx -V
nginx version: nginx/1.12.0 built with OpenSSL 1.0.2l-freebsd 25 May 2017 TLS SNI support enabled configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt='-I /usr/local/include' --with-ld-opt='-L /usr/local/lib' --conf-path=/usr/local/etc/nginx/nginx.conf --sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid --error-log-path=/var/log/nginx/error.log --user=www --group=www --modules-path=/usr/local/libexec/nginx --with-debug --with-file-aio --with-cc-opt='-DNGX_HAVE_INET6=0 -I /usr/local/include' --http-client-body-temp-path=/var/tmp/nginx/client_body_temp --http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp --http-proxy-temp-path=/var/tmp/nginx/proxy_temp --http-scgi-temp-path=/var/tmp/nginx/scgi_temp --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp --http-log-path=/var/log/nginx/access.log --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gzip_static_module --with-http_gunzip_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_stub_status_module --with-http_sub_module --with-pcre --with-http_v2_module --with-stream=dynamic --with-stream_ssl_module --with-stream_ssl_preread_module --with-threads --with-http_ssl_module |
Description
имеется конфиг следующего вида:
https://paste.ngx.cc/fa
ожидаемое поведение: запрашиваемый файл отдается клиенту и "оседает" локально на сервере.
имеющееся поведение: клиент файл получает, на сервере ничего не остается
но, если использовать http, то все работает так, как ожидается...
nginx, собранный с дебагом спамит очень активно и не понятно, что конкретно там нужно искать в логе :(
Change History (3)
follow-up: 2 comment:1 by , 7 years ago
comment:2 by , 7 years ago
Replying to mdounin:
Под "если использовать http" имеется в виду работа по http с клиентом?
да, верно, telnet server 80
GET /path/to/file.mp3 HTTP/1.1
Host: dll.domain.tld
<сюда выплевывается содержимое mp3`шки>
+ ls /zroot/path/to/file.mp3 показывает, что файл на сервере появляется.
Сохранение запрашиваемого файла с помощью
proxy_store
срабатывает только если ответ был 200, и файл получен полностью (Content-Length
совпадает с количеством полученных байт или отсутствует) и без ошибок. Использование https может менять поведение бекенда, так что в первую очередь смотреть стоит на него, особенно на ошибки, если они вдруг есть. Если не получается найти проблему самостоятельно - показывайте лог запроса, посмотрим.
бекенд в обоих случаях я не трогал - прописан в виде proxy_pass http://addr;
в его error логе ничего про "фронтэнд" нет. если есть минутка - можем в IRC обсудить в realtime, покажу debug лог, "обезличивать" его долго:(
В песочнице предложенная конфигурация работает без проблем во всех вариантах - http/https с клиентом, http/https с бекендом, запрошенные файлы штатно сохраняются куда сказано.
comment:3 by , 7 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
For the record: проблема была в том, что клиент посылает Range: 0-
, и соответственно от бекенда приходит 206 Partial Content. Каких-либо проблем со стороны nginx'а не выявлено.
Почему клиент делает так - тайна сия великая есть, вероятно - хочет узнать, поддерживает ли сервер range-запросы, или нет.
Если хочется сохранять ответы даже в том случае, если клиент использует range-запросы, следует убирать заголовок Range
с помощью директивы proxy_set_header
. Однако это может привести к другим нежелательным эффектам, если клиент таки ожидает range-ответ. Можно попробовать совместить с proxy_force_ranges
, чтобы клиенту таки возвращался range-ответ. Возможно, простейшим решением будет использовать proxy_cache
, там всё это будет работать само и сразу.
Под "если использовать http" имеется в виду работа по http с клиентом?
Сохранение запрашиваемого файла с помощью
proxy_store
срабатывает только если ответ был 200, и файл получен полностью (Content-Length
совпадает с количеством полученных байт или отсутствует) и без ошибок. Использование https может менять поведение бекенда, так что в первую очередь смотреть стоит на него, особенно на ошибки, если они вдруг есть. Если не получается найти проблему самостоятельно - показывайте лог запроса, посмотрим.В песочнице предложенная конфигурация работает без проблем во всех вариантах - http/https с клиентом, http/https с бекендом, запрошенные файлы штатно сохраняются куда сказано.