Кстати, насчет статусов. Заметил у nginx что если fastcgi отваливается по
таймауту, то в логе $status пишется как 0. При этом юзеру сообщается
правильный статус 504 (по помню точто, но Gateway Timeout сообщение там
было). При анализе логов это будет очень мешать.
Могу подтвердить. В ходе недавних экспериментов с залоченными скриптами
_иногда_ получалось вот что:
127.0.0.1 - - [22/Apr/2006:23:41:20 +0400] "GET /forum/usercp.php?
HTTP/1.1" 0 0 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1)
Gecko/20060208 SeaMonkey/1.5a"
127.0.0.1 - - [22/Apr/2006:23:56:51 +0400] "GET /forum/usercp.php?
HTTP/1.1" 504 183 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1)
Gecko/20060208 SeaMonkey/1.5a"
Это при fastcgi_read_timeout 15m при двух последовательных запросах к
"зависшему" скрипту, первый таймаут в серии получился с нулевым
статусом, клиенту посылается 504, при этом в error_log:
2006/04/22 23:41:20 [info] 10651#0: *831 client closed prematurely
connection, so upstream connection is closed too while sending request
to upstream, client: 127.0.0.1, server: test, URL: "/forum/usercp.php?",
upstream: "fastcgi://127.0.0.1:1234", host: "test"
2006/04/22 23:56:51 [error] 10669#0: *833 upstream timed out (110:
Connection timed out) while reading response header from upstream,
client: 127.0.0.1, server: test, URL: "/forum/usercp.php?", upstream:
"fastcgi://127.0.0.1:1234", host: "test"
К сожалению, какой-то закономерности уловить не удалось, чаще всего в
лог пишется правильный статус 504, но изредка проскакивает 0.
На первом запросе клиенту вообще ничего не посылается, потому что
он закрыл соединение ещё до того, как апстрим что-то передал.
В 0.3.42 nginx будет писать специальный код 499 - клиент закрыл
соединение до того, как ему хоть что-то было передано.
Игорь Сысоев
