Show all posts by user
Discussions in German
В HTTP спецификации, имена заголовков должны быть регистро независимы.
Нам на бекенде удобней отдавать все в нижнем регистре, проблем с Nginx или другими прокси не будет?
by
S.A.N
-
Nginx Mailing List - Russian
> > Как понимать "не атомарны"? Может отдаться часть слайса?
>
> Модуль slice разбивает запрос к бекенду на много range-запросов, а
> при отдаче клиенту полученные ответы склеиваются. Соответственно
> если в пр
by
S.A.N
-
Nginx Mailing List - Russian
> А от его необработки - теряется корректность возвращаемых ответов,
> и, e.g., клиенту, который не понимает gzip, может быть возвращён
> сжатый ответ из кеша. Т.е., фактически, клиент не получит ответ.
> И, более того, а
by
S.A.N
-
Nginx Mailing List - Russian
> Поддерживаю Антона: поведение совершенно неожиданное, и к тому же
> никак не описанное в документации. Прежде всего нужно эту засаду
> задокументировать, чтобы прилежные читатели не налетали на грабли.
Это не
by
S.A.N
-
Nginx Mailing List - Russian
> Но проблема несколько шире. Уже много фреймфорков написанных чисто на
> http 2.0 (gRPC - и это только начало), которые не содержат большого
> количества ненужного кода для поддержки http 1.1 просто потому что он
> не нужен
by
S.A.N
-
Nginx Mailing List - Russian
> Теперь законный вопрос, что же не так я делаю с ним:
> zend_extension="/usr/local/lib/php/20100525/eaccelerator.so"
Если есть возможность, обновите версию РНР до 5.6, там из коробки отличный OPCache, eAccelerator ненужен.
by
S.A.N
-
Nginx Mailing List - Russian
Если бекенд, выдаст заголовок:
Link: <my.js>; rel=preload; as=script
Nginx, отдаст браузеру содержимое файла my.js или только заголовок от бекенда?
by
S.A.N
-
Nginx Mailing List - Russian
После очередной настройки проксирования websocket сервера, меня все больше удивляет, почему в Nginx нет модуля websocket, c директивами websocket_*?
Модуль нужен не только для красоты конфига, он может хранить под капотом оптимальные
by
S.A.N
-
Nginx Mailing List - Russian
> Есть стандартное решение, которое работает с любым кэшем: nginx-а,
> memcached-а и т.д.
>
> В значение ключа кэширования добавьте счётчик. Отдельный для каждого
> куска кэша, который хотите вычищать. Когда надо буде
by
S.A.N
-
Nginx Mailing List - Russian
Amanda Sproule Wrote:
-------------------------------------------------------
> >>И возьмём упомянутые 400 location.
>
> поправлю - не локейшенов а server контекстов.
Да, для такого хозяйства нужен менеджер конфигов.
Советую ещё вспомнить что Nginx это рев
by
S.A.N
-
Nginx Mailing List - Russian
> А я думал, что конфиг _декларативный_, а из _императивного_ там
> только
> if-is-evil. Кто из нас ошибается(?), мне интересно... O_o
Если бы конфиг Nginx, был декларативным, вместо директив были бы декларации :), наличия директи
by
S.A.N
-
Nginx Mailing List - Russian
> Согласен, приведите аргументы к выше указанному вопросу и на этом
> закончим
> разговор.
Лучший аргументом может быть два примера решения вашей задачи, один с использованием наследования директив, второй вариа
by
S.A.N
-
Nginx Mailing List - Russian
> Начать тут нужно с того, что php не thread safe и может безопасно
> исполняться
> только в отдельных процессах. Пулы потоков ему ни чем не помогут.
В РНР есть модификация - ZTS (Zend Thread Safety), но там тоже конечно не все так хор
by
S.A.N
-
Nginx Mailing List - Russian
Почитал статью про thread pools в Nginx, появилась надежда что когда-то появится Nginx модуль РНР, который будет обрабатывать запросы к РНР скриптам внутри процеса Nginx (без блокировки, каждый скрипт использует свободный thread из пул
by
S.A.N
-
Nginx Mailing List - Russian
> как решить проблему добавления слеша в конец?
Офтоп - никогда не понимал, зачем бороться со слешами в конце uri, их можно использовать на бекенде в алгоритмах роутинга.
Например в наших роутингах слеш в конце означае
by
S.A.N
-
Nginx Mailing List - Russian
> Это разные запросы. Кроме php есть же и другие языки. Например в java
> и RoR
> массивы передаются в GET именно так как вы написали.
В java и RoR, чтобы передать масив id, нужно писать id=1&id=100?
Жаль конечно, в РНР масивы переда
by
S.A.N
-
Nginx Mailing List - Russian
Есть нормализованная переменная $uri, но нет нормализованной $args, но она реально нужна, попробую объяснить.
Наш ключ к кешу и REQUEST_URI к бекенду = $uri$is_args$args, нормализованный $uri очень удобен, но не нормализованный $args создает
by
S.A.N
-
Nginx Mailing List - Russian
> Однако в целом мне такой подход кажется куда более правильным, чем
> неочевидные проверки параметра HTTPS (который тоже ни разу не
> стандартный), и наверное добавить в fastcgi_params по умолчанию
> стоит.
Ок, спасибо.
by
S.A.N
-
Nginx Mailing List - Russian
РНР скрипты которые работали под Apache, получали перемененную окружения REQUEST_SCHEME, в fastcgi_params этот параметр не назначается, я прописал fastcgi_param REQUEST_SCHEME $scheme.
Вопрос, не нарушил ли я спецификацию FastCGI, если нет, тогда почему э
by
S.A.N
-
Nginx Mailing List - Russian
> Поверх этого кода есть ещё прослойка в виде php_fpm. Возможно что он
> смотрит на метод.
Да, php_fpm не отдает тело ответа, если REQUEST_METHOD = HEAD.
Эти нюансы могут стать проблемой, для РНР скриптов которые работали под Апачем,
by
S.A.N
-
Nginx Mailing List - Russian
> fastcgi_param REQUEST_METHOD $request_method;
> Cтрого говоря в случае протокола FastCGI такого понятия, как запрос
> "HEAD методом" не существует
Спасибо, теперь все понятно.
by
S.A.N
-
Nginx Mailing List - Russian
> В новых версиях ничего не менялось в этом отношении.
В Nginx/1.9.1, с включенным кэшированием, на бекенд отправляется запрос HEAD методом.
Вот простой скрипт РНР.
<?php
header('Cache-Control: max-age=1000');
header("X-Method: $_SERVER");
echo 'BOD
by
S.A.N
-
Nginx Mailing List - Russian
При запросе методом HEAD, в кеше сохраняются только заголовки ответа.
При следующем запросе методом GET, Nginx отдает из кеша ответ в котором нет тела, только заголовки.
Раньше Nginx при запросе методом HEAD, на бекенд отправлял
by
S.A.N
-
Nginx Mailing List - Russian
> хм...интересная идея..у меня Касперский...попробую вечером его
> выключить...но как тогда объяснить что он не разжимает на лету css и
> js
Вы можете проверить на других сайтах, например http://habrahabr.ru/ если в ответе не буде
by
S.A.N
-
Nginx Mailing List - Russian
> Хотя если выполнить wget с аналогичными броузерными заголовками, то
> все в порядке - приходит такой ответ
Возможно ваш антивирус или фаирвол, делает декомпресию на лету, тогда ваш браузер будет приходить незжатые
by
S.A.N
-
Nginx Mailing List - Russian
> Он отдает Transfer-Encoding: chunked когда размер ответа заранее
> неизвестен.
Я это понимаю, но думал что где-то на уровне буферизации ответа, Nginx может узнать что тело пустое, то того как начал передавать клиенту заголовки от
by
S.A.N
-
Nginx Mailing List - Russian
По умолчанию, Nginx отдает ответ Transfer-Encoding: chunked, даже когда длина тела ответа равна нулю.
Это мелочь, но будет лучше, если в этой ситуации Nginx будет отдавать Content-Length: 0.
Такой ответ короче и более удобный для HTTP клиентов.
by
S.A.N
-
Nginx Mailing List - Russian
mainline version будет 1.9, или будет только одна ветка stable а mainline удалите?
Я спрашиваю, чтобы правильно отредактировать путь для repo в CentOS, сейчас так:
http://nginx.org/packages/mainline/centos/7/$basearch/
Этот baseurl останется актуальным?
by
S.A.N
-
Nginx Mailing List - Russian