Если имеется такая конструкция в конфиге
location / {
root
/web1/users/mds_rudn/www/download.mds.rudn.info/htdocs/;
proxy_pass http://127.0.0.1:80;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-NGX-Request NGX;
proxy_set_header Host $http_host;
index index.html index.htm;
}
И бекенд выдает X-Accel-Redirect - редирект идет снова через proxy_pass
хост? Как этого избежать, т.е. что бы nginx выдавал файл сам по uri
взятому из X-Accel-Redirect с корнем сайта root.
Возможно ли настроить nginx так, чтобы в случае если нет заголовка
Last-Modified в ответе от бакенда, nginx сам подставлял текущее время в
этот заголовок.
--
Zherdev Anatoly.
Изменения в nginx 0.3.12 26.11.2005
*) Безопасность: если nginx был собран с модулем
ngx_http_realip_module, то при использовании директивы "satisfy_any
on" директивы доступа и аутентификации не работали. Модуль
ngx_http_realip_module не собирался и не собирается по умолчанию.
*) Изменение: имя переменной "$time_gmt" изменено на "$time_local".
*) Изменение: директивы proxy_header_buffer_size и
fastcgi_header_buffer_size переименованы соответственно в
proxy_buffer_size и fastcgi_buffer_size.
*) Добавление: модуль ngx_http_memcached_module.
*) Добавление: директива proxy_buffering.
*) Исправление: изменение в работе с accept mutex при использовании
метода rtsig; ошибка появилась в 0.3.0.
*) Исправление: если клиент передал строку "Transfer-Encoding: chunked"
в заголоовке запроса, то nginx теперь выдаёт ошибку 411.
*) Исправление: при наследовании директивы auth_basic с уровня http в
строке "WWW-Authenticate" заголовка ответа выводился realm без
текста "Basic realm".
*) Исправление: если в директиве access_log был явно указан формат
combined, то в лог записывались пустые строки; ошибка появилась в
0.3.8.
*) Исправление: nginx не работал на платформе sparc под любыми OS,
кроме Solaris.
*) Исправление: в директиве if теперь не нужно разделять пробелом
строку в кавычках и закрывающую скобку.
Игорь Сысоев
http://sysoev.ru
Изменения в nginx 0.1.38 08.07.2005
*) Добавление: директива limit_rate поддерживается в режиме прокси и
FastCGI.
*) Добавление: в режиме прокси и FastCGI поддерживается строка
заголовка "X-Accel-Limit-Rate" в ответе бэкенда.
*) Добавление: директива break.
*) Добавление: директива log_not_found.
*) Исправление: при перенаправлении запроса с помощью строки заголовка
"X-Accel-Redirect" не изменялся код ответа.
*) Исправление: переменные, установленные директивой set не могли
использоваться в SSI.
*) Исправление: при включении в SSI более одного удалённого подзапроса
мог произойти segmentation fault.
*) Исправление: если статусная строка в ответе бэкенда передавалась в
двух пакетах, то nginx считал ответ неверным; ошибка появилась в
0.1.29.
*) Добавление: директива ssi_types.
*) Добавление: директива autoindex_exact_size.
*) Исправление: модуль ngx_http_autoindex_module не поддерживал длинные
имена файлов в UTF-8.
*) Добавление: IMAP/POP3 прокси.
Игорь Сысоев
http://sysoev.ru
Изменения в nginx 0.3.19 28.12.2005
*) Добавление: директивы path и alias поддерживают переменные.
*) Изменение: теперь директива valid_referers опять учитывает URI.
*) Исправление: ошибки в обработке SSI.
Игорь Сысоев
http://sysoev.ru
Здравствуйте!
Я писал это письмо в рассылку apache-list, но у меня сложилось
впечатление, что безуспешно (то ли рассылка не работает, то ли лыжи не
едут....)
Пытаюсь выстроить следующую схему:
Nginx <=> Apache/mod_accel <=> Apache/mod_php
Nginx самостоятельно отдает статику, а для получения ответа скриптов
передает запрос дальше. Я хочу сделать чтобы mod_accel параллельные
запросы к скриптам на каждый вирт. хост выстраивал в очередь, а не
сваливал разом на бекэнд, т. е. одновременно задействовал только 2
подключения (по числу процессоров).
Вот как я это попытался сделать (выдержка из конфига среднего апача):
Timeout 75
KeepAlive Off
Listen 127.0.0.1:8080
RealIP 127.0.0.1
AccelCacheRoot /tmp/accel
AccelNoCache On
AccelTimeout 75 75
AccelBusyLock 75 75 75
AccelPass / http://localhost:80/ [MC=2,MW=50,PH]
Однако на практике происходит следующее: когда я с помощью ab пытаюсь
запросить в 20 потоков, 2 первых запроса начинают заниматься
действительно получением ответа, а все остальные вместо того чтобы
ждать - мгновенно отваливаются.
Вопрос - что я не так делаю?
--
Alexey Polyakov
День добрый,
Вот тут столкнулся с какими-то неясными проблемами в fastcgi.
Пытаюсь мигрировать с lighttpd на ngnix, соответственно собираем nginx
0.3.18 и имеем установленный lighttpd 1.4.8
Есть куски конфигов:
nginx:
...
server {
listen 80;
charset off;
location / {
fastcgi_pass 127.0.0.1:8801;
fastcgi_index /;
fastcgi_param QUERY_STRING $query_string;
fastcgi_param PATH_TRANSLATED $fastcgi_script_name;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
}
}
...
Есть lighttpd.conf:
...
fastcgi.server = ( "/" => ( (
"host" => "127.0.0.1",
"port" => 8801,
"check-local" => "disable",
"docroot" => "/"
) )
)
...
Есть два скрипта, один использует стандартный CGI::Fast, и не
наблюдается ни каких проблем:
use strict;
use CGI::Fast;
my $COUNTER = 0;
while( my $cgi = CGI::Fast->new ) {
my $content = join( '',
$cgi->start_html(
-title => "Fast CGI Rocks",
-encoding=> 'windows-1251',
),
$cgi->h1("Fast CGI Rocks"), "Invocation number ",
$cgi->b($COUNTER++), " PID ", $cgi->b($$),".",
$cgi->hr,"\n",
$cgi->end_html,
"\n",
);
print
$cgi->header(
-charset => 'windows-1251',
-content_type => 'text/html',
-content_length => length( $content )
),
$content;
}
Есть то-же самое, но использующее POE:
use strict;
use lib qw(.);
use HTTP::Request;
use HTTP::Response;
use POE::Component::FastCGI;
$| = 1;
my $COUNTER = 0;
POE::Component::FastCGI->new(
Address => '127.0.0.1',
Port => 8801,
Handlers => [
[ '/' => \&default ],
[ '' => \&default ],
],
);
POE::Kernel->run();
print "\nAll done\n";
exit 0;
sub default {
my ( $request ) = @_;
my $response = $request->make_response;
my $content = join( "\n",
qq{<!DOCTYPE html\n\tPUBLIC "-//W3C//DTD XHTML 1.0
Transitional//EN"\n\t
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">},
qq{<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US"
xml:lang="en-US">},
qq{<head>},
qq{<title>Fast CGI Rocks</title>},
qq{<meta http-equiv="Content-Type" content="text/html;
charset=windows-1251" />},
qq{</head>},
qq{<body>},
qq{<h1>Fast CGI Rocks</h1>Invocation number <b>$COUNTER</b>
PID <b>$$</b>.<hr />},
'',
qq{</body>},
qq{</html>},
''
);
print STDERR "Accept request accept\n";
$response->header(
"Content-type" => "text/html; charset=windows-1251",
"Content-Length" => length( $content ),
);
$response->content( $content );
$response->send;
$COUNTER++;
print STDERR "Response sent\n";
}
Из под lighttpd все нормально, а вот в случае nginx приходит запрос,
скрипт выдает ответ, но на строну клиента ничего не выводится... Хотя
если убить скрипт - то выводится то, что должно вывестись. То есть
какая-то проблема с буферизацией.
Может быть кто-нибудь сталкивлася с подобной проблемой ?
P.S.
На всякий случай прилагаю все скрипты и трафик снятый tcpdump-ом в
случае с nginx и lighttpd в виде tar.gz.
По tcpdump-логам:
lighttpd.dat - Это нормальная сессия по fastcgi протоколу между
скриптом и lighttpd
nginx.dat - Сессия между скриптом и nginx причем запись прекращена
спустя 5 секунд после запроса
nginx2.dat - то же самое, но после запроса ~ 10 сек скрипту был послан
сигнал SIGINT (^C)
Система debian unstable.
--
Andrey Chernomyrdin
Изменения в nginx 0.3.18 26.12.2005
*) Добавление: директива server_names поддерживает имена вида
".domain.tld".
*) Добавление: директива server_names использует хэш для имён вида
"*.domain.tld" и более эффективный хэш для обычных имён.
*) Изменение: директивы server_names_hash_max_size и
server_names_hash_bucket_size.
*) Изменение: директивы server_names_hash и server_names_hash_threshold
упразднены.
*) Добавление: директива valid_referers использует хэш для имён сайтов.
*) Изменение: теперь директива valid_referers проверяет только имена
сайтов без учёта URI.
*) Исправление: некоторые имена вида ".domain.tld" неверно
обрабатывались модулем ngx_http_map_module.
*) Исправление: если конфигурационного файла не было, то происходил
segmentation fault; ошибка появилась в 0.3.12.
*) Исправление: на 64-битных платформах при старте мог произойти
segmentation fault; ошибка появилась в 0.3.16.
Игорь Сысоев
http://sysoev.ru
Здравствуйте!
После апгрейда на 0.3.18 получил вот такое сообщение:
2005/12/28 10:46:43 [emerg] 77249#0: could not build the server_names_hash hash, you should increase server_names_hash_bucket_size: 32
Что оно означает и до какой величины нужно увеличивать
server_names_hash_bucket_size? Сейчас добавил в конфиг
server_names_hash_bucket_size 64
Вроде работает.
--
DSS5-RIPE DSS-RIPN 2:550/5068@fidonet 2:550/5069@fidonet
mailto:dsh@vlink.ru http://neva.vlink.ru/~dsh/