Добрый день. Google откуда-то взял битую ссылку вида /…/%D0% (с неверным percent-кодированием). Хотелось бы перенаправить его на корректную страницу, но nginx возвращает 400 Bad request уже при декодировании request_uri и до перенаправленияby gz - Nginx Mailing List - Russian
Илья Шипицин Wrote: ------------------------------------------------------- > у вас же должны быть логи по html страницам и по css-файлам. > посмотрите на них. > если > > а) у вас хорошее кеширование (т.е. ноль 304-х) > б) количество ответов css соотвby gz - Nginx Mailing List - Russian
> насчет действительно связанных css и js - в принципе можно их > эмбедить > прямо в html разметку. и отдавать вместе с основной страницей. > тот же push. Только без потенциального выигрыша в попадании из push-кэша в основнby gz - Nginx Mailing List - Russian
Evgeniy Berdnikov Wrote: ------------------------------------------------------- > On Wed, Apr 29, 2020 at 01:26:27PM -0400, gz wrote: > > Но предполагаю, что клиенту отказаться от push'а проще, чем сделать > > дополнительный запрос к ресурсу. > > Если клиент умеет cache digesby gz - Nginx Mailing List - Russian
S.A.N Wrote: ------------------------------------------------------- > > Решение о push'е принимается при генерации HTML-ответа за запрос к > > странице. > > В этот момент доступны If-None-Match и/или If-Modified-Since только > > самой страницы и странно ориенby gz - Nginx Mailing List - Russian
Maxim Dounin Wrote: ------------------------------------------------------- > Это общий принцип работы переменных $1..$9 приблизительно везде, > так что он, видимо, в явном виде в документации не описан. Отчасти да, но неочевидно, что location и map работаюby gz - Nginx Mailing List - Russian
nginx/1.17.10 При использовании регулярных выражений в map обнуляются выделения уровня location, даже в случае, если в выражениях map не используются выделения. https://nginx.org/ru/docs/http/ngx_http_map_module.html > Регулярное выражение может содеby gz - Nginx Mailing List - Russian
> Советую смотреть не на куки, а на наличия клиенских заголовков - > If-None-Match и/или If-Modified-Since, только при отсутствии или не > валидности данных заголовков делать push. > Из нашего опыта - push полезен только для клиентов уby gz - Nginx Mailing List - Russian
> > Востребованные ресурсы из push-кэша переходят в основной и будут > > использованы для следующих страниц. > > Клиенты умеют отказываться от проталкиваемых ресурсов, уже имеющихся > в > > кэше. > > В крайнеby gz - Nginx Mailing List - Russian
> > Maxim Dounin Wrote: > > ------------------------------------------------------- > > > > В HTML страницы бэкендом выдаются элементы <link rel="preload"> > с > > > указанием > > > > на ресурсы для предзагрузки. > > > > Хотелось бы переby gz - Nginx Mailing List - Russian
Maxim Dounin Wrote: ------------------------------------------------------- > > В HTML страницы бэкендом выдаются элементы <link rel="preload"> с > указанием > > на ресурсы для предзагрузки. > > Хотелось бы перейти с предзагрузки на http2_push указаннby gz - Nginx Mailing List - Russian
В HTML страницы бэкендом выдаются элементы <link rel="preload"> с указанием на ресурсы для предзагрузки. Хотелось бы перейти с предзагрузки на http2_push указанных ресурсов. Казалось бы, нет проблемы перейти на заголовок Linkby gz - Nginx Mailing List - Russian
> Попробуйте https://github.com/openresty/set-misc-nginx-module Спасибо. Странно, что nginx не делает такой простой вещи.by gz - Nginx Mailing List - Russian
> Обращаю внимание - выше написано _с_отдельными_переменными_. Это важно. > Ну или вообще выкинуть переменные из конструкции, насколько я > понимаю - они тут не нужны, достаточно соответствующие > fastcgi_param задать яby gz - Nginx Mailing List - Russian
> Это не подзапрос баннера. Это подзапрос > fastcgi_cache_background_update. Но в нём используются те же > переменные, что уже перезаписаны подзапросом баннера, и в > результате на бэкенд уходит неправильное значение переменноby gz - Nginx Mailing List - Russian
> Вопрос не в том, что используется в ключе кэширования, а в том, > что отправляется на бэкенд. И на бэкенд у вас при перезаписи как > раз отправляется $handler, установленный в другом подзапросе: > 2018/04/09 21:29:34 16867#16867: *1by gz - Nginx Mailing List - Russian
> Наиболее вероятную причину я озвучил тут: > http://mailman.nginx.org/pipermail/nginx-ru/2018-April/061095.html > Если предположение верно, то исправлять нужно конфигурацию. Я спустя двадцать минут ответил — https://forum.nginx.org/read.php?21,279356,279365#msg-279365by gz - Nginx Mailing List - Russian
Коллеги, каковы дальнейшие действия, чтобы исправить причину ошибки? От меня требуется пример конфигурации или лога достаточно для выявления причины перезаписи файла кэша основного запроса из подзапроса? Всё корреby gz - Nginx Mailing List - Russian
> Есть возможность использовать функциональность njs для сериализации аргументов запроса. Спасибо, посмотрю. Но, всё же, считаю, что nginx'у стоило был самому делать uri-encoding параметров запроса. > Однако, в общем случby gz - Nginx Mailing List - Russian
Добрый день. Использую SSI для включения ответа стороннего сервера. <!--#include virtual="/include/"--> location /include { internal; proxy_pass http://example.com/endpoint?server=$server_name&uri=$request_uri&ua=$http_user_agent; } Серверу нужно передать ряд GET-параметрby gz - Nginx Mailing List - Russian
> А как используются переменные $handler и $querystring? Устанавливаются переменные окружения для FCGI-процесса: fastcgi_param QUERY_STRING $querystring; fastcgi_param PATH_TRANSLATED $document_root/$handler; Картина из лога: Кэш протух, обращение к бэкенду, сохраby gz - Nginx Mailing List - Russian
> Судя по приведённому debug log'у, в кэше лежит валидный ответ > бэкенда с "Status: 200" и "Content-Length: 0", который и отдаётся > клиенту. > Очевидно, что ответ этот nginx не сам придумал, а получил от > бэкенда. Почему бby gz - Nginx Mailing List - Russian
> Причина в том, что в документации для директивы fastcgi_cache_key > указано некорректное с точки зрения протокола HTTP значение > localhost:9000$request_uri - так оно нормально работать не будет. Я использую сокет: upstream fcgiwrap { server unixby gz - Nginx Mailing List - Russian
> Попробуйте включить debug log в nginx'е, возможно происходящее станет понятнее. Понятнее не стало. ------------------------------------------------- 2018/04/09 18:21:23 29576#29576: *3395329 using configuration "/" 2018/04/09 18:21:23 29576#29576: *3395329 http cl:-1 max:104857600 2018/04/09 18:21:23by gz - Nginx Mailing List - Russian
Что характерно, при этом до апстрима запрос вообще не доходит. Включил логирование в приложении: смену статуса в логе nginx вижу, генерации ответа fastcgi-приложением не происходит.by gz - Nginx Mailing List - Russian
Добрый вечер. При использовании fastcgi_cache_background_update наблюдаю странное поведение nginx. Адрес недоступен, в кэше лежит ответ со статусом 404. По истечении времени жизни кэша вместо обращения к апстриму и сохранения ответаby gz - Nginx Mailing List - Russian
> попробуйте map Не понимаю как map мне в этом поможет. Количество переменных в строке произвольное, даже если делать несколько замен с запасом несколькими картами, найдя имя переменной невозможно обратиться к ней — $$by gz - Nginx Mailing List - Russian
Подскажите пожалуйста, есть ли способ произвести замену переменных строки (например, в значении заголовка ответа, полученного от апстрима) на их значения? … set $var_1 one; set $var_2 two; … some_string_${var_1}_${var_2} → some_string_one_two Покby gz - Nginx Mailing List - Russian
Укажите флаг volatile, чтобы значения не кэшировались после первого вычисления в рамках основного запроса. map $request_uri $fastcgi_cache_key { volatile; default $request_method|$host|$uri|$request_uri|$cookie_currency|$cookie_show_mode; ~^/objekti/.+ $request_method|$host|$uri|$request_uri|$cookie_curreby gz - Nginx Mailing List - Russian
> Вместо копирования надо использовать include Для 3-5 общих и пары заголовков уровнем ниже, include — это перебор.by gz - Nginx Mailing List - Russian