Варнинги от Nginx в версии 14.2

[Alex-GR 5]

Добрый день!

При переходе на версию 14.2 в логах Nginx появились предупреждения вида:

[warn] 27840#27840: *85737 upstream sent more data than specified in "Content-Length" header while reading upstream, client: 66.249.76.61, server: ...

Они возникают в момент обращения поисковиков к страницам сайта: поисковик делает запрос на сайт с заголовком If-Modified-Since или If-None-Match и если контент страницы не изменился, движок отдает код "304 Not Modified" - именно в этом случае возникает ошибка.  Кто подскажет, как можно убрать эти предупреждения?

Сайт - avtoforex.ru

Изменено 15 апреля 2021 пользователем Alex-GR

[celsoft 6 082]

Вообще не имеет никакого отношения к DLE и к версии DLE. Ошибка говорит что на сервер было посланы данные которые превышают лимиты установленные на сервере. DLE работает на сервере. А данные посылает не DLE, а пользователь сайта, например браузер или вообще любой клиент.

[Alex-GR 5]

3 часа назад, celsoft сказал:

Вообще не имеет никакого отношения к DLE и к версии DLE. Ошибка говорит что на сервер было посланы данные которые превышают лимиты установленные на сервере. DLE работает на сервере. А данные посылает не DLE, а пользователь сайта, например браузер или вообще любой клиент.

Имеет отношение к DLE. При запросе поисковиков с заголовком If-Modified-Since DLE возвращает ответ "HTTP/1.1 304 Not Modified" и "Content-Length  0" именно Nginx, который принимает не нулевые данные, указанные в заголовке Content-Length и посланные DLE. Не снаружи, а внутри. Отсюда и варнинг.

Тут данные посылаются не на сервер, а идет ответ на запрос поисковика с DLE на Nginx, и в заголовках и реальных данных расхождение. Как решить эту проблему?

[celsoft 6 082]

19 часов назад, Alex-GR сказал:

При запросе поисковиков с заголовком If-Modified-Since DLE возвращает ответ "HTTP/1.1 304 Not Modified" и "Content-Length  0"

Так вообще то и должно быть. Возвращается только заголовок и больше ничего. DLE сделан все правильно. Но по тексту у вас "upstream sent more data than specified in "Content-Length"" в прокси пришло с потока больше данных, чем указано. Но DLE не указывает сколько данных идет в Content-Length он этим параметром не управляет вообще, его ставит апач автоматически от контента, он поставил 0, это по сути правильно, а пришло больше. Могу лишь предположить, что что то с настройками буфферизации не то, и помимо контента что то из буффера идет. Но это лишь предположение, что сервер некорректно работает с нулевыми данными.

С DLE тут точно все в порядке, контент и должен быть нулевой, только заголовок и все.

[Alex-GR 5]

6 часов назад, celsoft сказал:

его ставит апач

Апача нет. Nginx + PHP-FPM.

Я, конечно, только учусь. Но я докопаюсь до причины.

Не понятно, почему вы так против. Я обозначил проблему, и я её решу.

Вам то легче её решить. У вас знаний и опыта больше. Но если не хотите - ваше право. Напрягает отношение к клиентам.

13 лет я с вами. И вы тихонечко посылаете меня на.... Почему? За что?

Впрочем, это ваше право. Зря я лицензии покупал. C таким отношением...

[ZzzBep 18]

Поверьте мне здесь отношение ещё нормальное.😃 Без наездов задавайте правильные вопросы и получите ответ.

[celsoft 6 082]

14 часов назад, Alex-GR сказал:

Не понятно, почему вы так против.

Против чего? Я не очень понимаю?

14 часов назад, Alex-GR сказал:

Вам то легче её решить. У вас знаний и опыта больше. Но если не хотите - ваше право. Напрягает отношение к клиентам.

13 лет я с вами. И вы тихонечко посылаете меня на.... Почему? За что?

Я могу вам помочь и решать только те проблемы, которые в компетенции DLE. Мы не можем настраивать и тюнинговать сервер каждому, и искать нестыковки в конфигурациях серверов. Вопросы настройки серверов вне нашей компетенции, мы же не продаем серверов. С такими вопросами вам нужно обратиться к тому кто вам продал сервер, настраивал его. Это же не мы. А вы хотите этого от нас. Все что касается DLE, это к нам, все что его не касается его, это уже вам не к нам нужно обращаться.

14 часов назад, Alex-GR сказал:

Апача нет. Nginx + PHP-FPM.

Значит посмотрите настройки буферизации в PHP. Буферизацию вообще нужно отключить по хорошему.

[Alex-GR 5]

Как я и обещал, я решил причину вывода предупреждения Nginx. Это баг DLE версии 14.2.

Виновником оказался код DLE, а вернее невнимательность его разработчиков.

Для начала хочу напомнить celsoft-ту вот это правило: https://www.php.net/manual/ru/function.header.php

Оно гласит: "Помните, что функцию header() можно вызывать только если клиенту ещё не передавались данные. То есть она должна идти первой в выводе, перед её вызовом не должно быть никаких HTML-тегов, пустых строк и т.п.".

Теперь смотрим файл /engine/modules/functions.php, в котором прописана функция GzipOut. В ней проверяются 2 условия - в запросе должен быть заголовок If-Modified-Since и сравнивается дата изменения документа с датой, переданной в заголовке If-Modified-Since. Все верно, все работает правильно.

Теперь смотрим, где вызывается функция GzipOut? Это файл /engine/modules/main.php, самый конец. А чуть выше идёт передача данных клиенту:

echo $tpl->result['main'];
echo "\n<!-- DataLife Engine Copyright SoftNews Media Group (http://dle-news.ru) -->\r\n";

Нарушено приведённое выше правило для функции header(). Вырезаем код проверки даты из функции GzipOut и вставляем его выше строки

echo $tpl->result['main'];

И о чудо - все работает правильно, предупреждений от Nginx нет, не нужно "настраивать и тюнинговать сервер и искать нестыковки в конфигурациях"!
Остались только те проблемы, которые в компетенции DLE, верно?

[proba 57]

А ещё:

11 часов назад, Alex-GR сказал:

чуть выше идёт

в файлах, index.php, admin.php, ..., строка:

ob_start();

и

11 часов назад, Alex-GR сказал:

передача данных клиенту

не идёт ранее отправления заголовков в GzipOut().

11 часов назад, Alex-GR сказал:

верно?

Нет!

[Alex-GR 5]

11 минут назад, proba сказал:

Нет!

Тогда как вы объясните тот момент, что варнинги перестают сыпаться в лог ошибок после переноса кода проверки даты с функции GzipOut выше первого echo в файле /engine/modules/main.php?

[Alex-GR 5]

И ещё - сделайте простую проверку того, что данные передаются до вывода заголовка 304 Not Modified: в файле /engine/modules/functions.php закомментируйте строку и добавьте echo, чтобы быть уверенным, что отрабатывает именно этот код:

//header($_SERVER['SERVER_PROTOCOL'] . ' 304 Not Modified');
echo 'Есть данные';

и через curl отправьте запрос с указанием заголовка If-Modified-Since - вы получите код сайта и в конце текст "Есть данные", хотя кода быть не должно! Вывод должен быть нулевым.

Изменено 18 апреля 2021 пользователем Alex-GR

[Alex-GR 5]

А если вы перед эхо очистите буфер - то код сайта выводится не будет, только строка "Есть данные":

if ($IfModifiedSince && $IfModifiedSince >= $_DOCUMENT_DATE) {
	//header($_SERVER['SERVER_PROTOCOL'] . ' 304 Not Modified');
	ob_end_clean();
	echo 'Есть данные';
die();

 

Ну и "вишенка на торте". Вот такой код:

if ($IfModifiedSince && $IfModifiedSince >= $_DOCUMENT_DATE) {
	ob_end_clean();
	header($_SERVER['SERVER_PROTOCOL'] . ' 304 Not Modified');
	die();
}

отрабатывает без предупреждений со стороны Nginx.

[Alex-GR 5]

 И уж если, цитирую:

"Для публикаций добавлена поддержка отдачи заголовка "304 Not Modified", в случае отправки на сервер соответствующего запроса от поисковых систем. Если публикация не редактировалась за указанный период, то DLE будет отдавать просто короткий соответствующий HTTP с кодом 304. Что позволит снизить расход трафика на сервере, и несколько снизить нагрузку на сервер."

стоит задача снизить нагрузку на сервер, то стоит проверку модификации публикации организовать как можно ближе к получению переменной $_DOCUMENT_DATE из БД (или кеша), в файлах show.full.php и static.php, а не выполнять "туевую хучу" кода (в том числе и запросов к БД) до проверки модификации публикации бесполезно.

Изменено 18 апреля 2021 пользователем Alex-GR

[celsoft 6 082]

1 час назад, Alex-GR сказал:

стоит задача снизить нагрузку на сервер, то стоит проверку модификации публикации организовать как можно ближе к получению переменной $_DOCUMENT_DATE из БД (или кеша), в файлах show.full.php и static.php, а не выполнять "туевую хучу" кода (в том числе и запросов к БД) до проверки модификации публикации бесполезно.

Не стоит задача снижать нагрузку, и не может стоять, потому как контента может быть много на странице, есть еще комментарии, есть еще custom комментариев и т.д.

Задача стоит исключительно в том чтобы экономить трафик а также увеличивать скорость переиндексации т.к. поисковику не нужно самому обрабатывать контент. Все. Больше никаких задач не стоит в данном случае и стоять не может.

[Alex-GR 5]

23 минуты назад, celsoft сказал:

Не стоит задача снижать нагрузку, и не может стоять, потому как контента может быть много на странице, есть еще комментарии, есть еще custom комментариев и т.д.

Задача стоит исключительно в том чтобы экономить трафик а также увеличивать скорость переиндексации т.к. поисковику не нужно самому обрабатывать контент. Все. Больше никаких задач не стоит в данном случае и стоять не может.

Возможно это и так - вы разработчики, и вы знаете код лучше.

А баг ваш когда устраните?

[celsoft 6 082]

7 часов назад, Alex-GR сказал:

А баг ваш когда устраните?

Уже