Илья Шипицин Wrote:
---
> у вас же должны быть логи по html страницам и по css-файлам.
> посмотрите на них.
> если
>
> а) у вас хорошее кеширование (т.е. ноль 304-х)
> б) количество ответов css соответствует количеству отданных html страниц
>
>
> насчет действительно связанных css и js - в принципе можно их
> эмбедить
> прямо в html разметку. и отдавать вместе с основной страницей.
> тот же push.
Только без потенциального выигрыша в попадании из push-кэша в основной с
возможностью отказаться от получения ресурса в дальнейшем.
А если
S.A.N Wrote:
---
> > Решение о push'е принимается при генерации HTML-ответа за запрос к
> > странице.
> > В этот момент доступны If-None-Match и/или If-Modified-Since только
> > самой страницы и странно ориентироваться на них, так как они ничего
Maxim Dounin Wrote:
---
> Это общий принцип работы переменных $1..$9 приблизительно везде,
> так что он, видимо, в явном виде в документации не описан.
Отчасти да, но неочевидно, что location и map работают в одном контексте и
разделяют
nginx/1.17.10
При использовании регулярных выражений в map обнуляются выделения уровня
location, даже в случае, если в выражениях map не используются выделения.
https://nginx.org/ru/docs/http/ngx_http_map_module.html
> Регулярное выражение может содержать именованные и позиционные выделения,
> > Востребованные ресурсы из push-кэша переходят в основной и будут
> > использованы для следующих страниц.
> > Клиенты умеют отказываться от проталкиваемых ресурсов, уже имеющихся
> в
> > кэше.
> > В крайнем случае несложно пометить клиента стандартным способом
> через
> > cookie.
>
> Проблема
> Советую смотреть не на куки, а на наличия клиенских заголовков -
> If-None-Match и/или If-Modified-Since, только при отсутствии или не
> валидности данных заголовков делать push.
> Из нашего опыта - push полезен только для клиентов у которых нет
> валидного кеша, в этом случаи вы получите не
> > Maxim Dounin Wrote:
> > ---
> > > > В HTML страницы бэкендом выдаются элементы
> с
> > > указанием
> > > > на ресурсы для предзагрузки.
> > > > Хотелось бы перейти с предзагрузки на http2_push указанных
> ресурсов.
> > >
> > > А вы
Maxim Dounin Wrote:
---
> > В HTML страницы бэкендом выдаются элементы с
> указанием
> > на ресурсы для предзагрузки.
> > Хотелось бы перейти с предзагрузки на http2_push указанных ресурсов.
>
> А вы пробовали тестировать, что вы получите на
В HTML страницы бэкендом выдаются элементы с указанием
на ресурсы для предзагрузки.
Хотелось бы перейти с предзагрузки на http2_push указанных ресурсов.
Казалось бы, нет проблемы перейти на заголовок Link, который модулем
ngx_http_v2_module при http2_push_preload on будет преобразован в push'и.
> Обращаю внимание - выше написано _с_отдельными_переменными_. Это важно.
> Ну или вообще выкинуть переменные из конструкции, насколько я
> понимаю - они тут не нужны, достаточно соответствующие
> fastcgi_param задать явно.
Ясно.
С переменными удобно включать один файл, конструкции установки
> Это не подзапрос баннера. Это подзапрос
> fastcgi_cache_background_update. Но в нём используются те же
> переменные, что уже перезаписаны подзапросом баннера, и в
> результате на бэкенд уходит неправильное значение переменной
> PATH_TRANSLATED. И бэкенд, в свою очередь, отвечает на него в
>
> Наиболее вероятную причину я озвучил тут:
> http://mailman.nginx.org/pipermail/nginx-ru/2018-April/061095.html
> Если предположение верно, то исправлять нужно конфигурацию.
Я спустя двадцать минут ответил —
https://forum.nginx.org/read.php?21,279356,279365#msg-279365
Не думаю, что дело в
> Есть возможность использовать функциональность njs для сериализации
аргументов запроса.
Спасибо, посмотрю.
Но, всё же, считаю, что nginx'у стоило был самому делать uri-encoding
параметров запроса.
> Однако, в общем случае задача усложняется тем что содержимое $request_uri
может быть уже
> Попробуйте https://github.com/openresty/set-misc-nginx-module
Спасибо.
Странно, что nginx не делает такой простой вещи.
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,279411,279420#msg-279420
___
nginx-ru mailing list
Добрый день.
Использую SSI для включения ответа стороннего сервера.
location /include {
internal;
proxy_pass
http://example.com/endpoint?server=$server_name=$request_uri=$http_user_agent;
}
Серверу нужно передать ряд GET-параметров (не заголовков).
Однако, при передаче того
> Судя по приведённому debug log'у, в кэше лежит валидный ответ
> бэкенда с "Status: 200" и "Content-Length: 0", который и отдаётся
> клиенту.
> Очевидно, что ответ этот nginx не сам придумал, а получил от
> бэкенда. Почему бэкенд прислал именно такой ответ - надо смотреть
> в debug log'е в
> Причина в том, что в документации для директивы fastcgi_cache_key
> указано некорректное с точки зрения протокола HTTP значение
> localhost:9000$request_uri - так оно нормально работать не будет.
Я использую сокет:
upstream fcgiwrap {
serverunix:/var/run/fcgiwrap.socket;
> Попробуйте включить debug log в nginx'е, возможно происходящее
станет понятнее.
Понятнее не стало.
-
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 using configuration "/"
2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http cl:-1
Что характерно, при этом до апстрима запрос вообще не доходит.
Включил логирование в приложении: смену статуса в логе nginx вижу, генерации
ответа fastcgi-приложением не происходит.
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,279350,279351#msg-279351
Добрый вечер.
При использовании fastcgi_cache_background_update наблюдаю странное
поведение nginx.
Адрес недоступен, в кэше лежит ответ со статусом 404.
По истечении времени жизни кэша вместо обращения к апстриму и сохранения
ответа со статусом 404 в кэш и отдачи его клиенту выдаётся ответ
> попробуйте map
Не понимаю как map мне в этом поможет.
Количество переменных в строке произвольное, даже если делать несколько
замен с запасом несколькими картами, найдя имя переменной невозможно
обратиться к ней — $$name не работает.
Вы просто так предложили, или можете привести пример?
Подскажите пожалуйста, есть ли способ произвести замену переменных строки
(например, в значении заголовка ответа, полученного от апстрима) на их
значения?
…
set $var_1 one;
set $var_2 two;
…
some_string_${var_1}_${var_2} → some_string_one_two
Пока нашёл такое только в отдельных модулях,
Укажите флаг volatile, чтобы значения не кэшировались после первого
вычисления в рамках основного запроса.
map $request_uri $fastcgi_cache_key {
volatile;
default
$request_method|$host|$uri|$request_uri|$cookie_currency|$cookie_show_mode;
~^/objekti/.+
> Вместо копирования надо использовать include
Для 3-5 общих и пары заголовков уровнем ниже, include — это перебор.
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,277956,277971#msg-277971
___
nginx-ru mailing list
nginx-ru@nginx.org
Ясно, решение политическое.
Благодарю за пояснение.
> Вам не нужно просматривая все уровни вложенности и в уме суммировать
списки директив.
Эта необходимость, кстати, никуда не девается.
И если при обычном наследовании достаточно просмотреть 2-3 уровня (вложенные
location'ы в расчёт не берём) и
Знатоки, поясните пожалуйста, с какой целью в nginx сделано так, что
add_header и proxy_set_header «наследуются с предыдущего уровня при условии,
что на данном уровне не описаны свои директивы»?
Это же ужасно неудобно — хочется задать ряд общих заголовков на уровне
http/server, а в location'ах
27 matches
Mail list logo
