У меня есть ртутный веб-интерфейс (hgwebdir.cgi), установленный на сервере, и перед ним была установлена установка nginx в качестве обратного прокси-сервера для веб-интерфейса, как предложил мой друг. Однако всякий раз, когда проталкивается большой набор изменений (через скрипт), он терпит неудачу. Я нашел вопросник @ google-code которые описывают похожую проблему, и есть решение, которое говорит (# 39)
Итак, ответ на стороне сервера: не отправляйте 401 обратно раньше. Будьте такими же медленными / тупыми, как 'hg serve', и заставьте hg-клиент дважды отправить пакет.
Как я могу это сделать? Моя текущая конфигурация nginx
location /repo/testdomain.com {
rewrite ^(.*) http://bpj.kkr.gov.my$1/hgwebdir.cgi;
}
location /repo/testdomain.com/ {
rewrite ^(.*) http://bpj.kkr.gov.my$1hgwebdir.cgi;
}
location /repo/testdomain.com/hgwebdir.cgi {
proxy_pass http://localhost:81/repo/testdomain.com/hgwebdir.cgi;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_buffering on;
client_max_body_size 4096M;
proxy_read_timeout 30000;
proxy_send_timeout 30000;
}
В журнале доступа мы продолжаем видеть 408 записей
incoming.ip.address - - [18/Nov/2009:08:29:31 +0800] "POST /repo/testdomain.com/hgwebdir.cgi/example_repository?cmd=unbundle&heads=73121b2b6159afc47cc3a028060902883d5b1e74 HTTP/1.1" 408 0 "-" "mercurial/proto-1.0"
incoming.ip.address - - [18/Nov/2009:08:37:14 +0800] "POST /repo/testdomain.com/hgwebdir.cgi/example_repository?cmd=unbundle&heads=73121b2b6159afc47cc3a028060902883d5b1e74 HTTP/1.1" 408 0 "-" "mercurial/proto-1.0"
Могу ли я еще что-нибудь сделать на сервере, потому что решение на стороне сервера предпочтительнее: /
Bitbucket, похоже, решил эту проблему (проверьте проект bitbucket liquidhg и страницу вики диагностики) на стороне сервера, хотя нигде не может найти конфигурацию: /
Проблема в том, что httplib является полудуплексным, и серверы, которые агрессивно закрывают сокеты после ответа (в том числе nginx), вызывают запись httplib в сломанный канал. В версии 1.4 есть временное решение этой проблемы, но оно не ускоряет работу, просто меньше шансов полностью развалиться. Я не знаю, как настроить nginx, чтобы он делал то, что вы хотите, но я знаю, что при достаточно больших нажатиях BitBucket имеет ту же проблему.
Какую версию Apache и nginx вы используете? Для меня это может быть хорошим способом получить более «полную» тестовую установку.
Что вы используете для аутентификации? Что-то в двоичном файле Apache? Возможно, Apache слишком быстро хлопает дверью после неудачной аутентификации.
Кроме того, FWIW, liquidhg - замечательная работа Брэда Олсона, и она просто размещена на BitBucket. Просто хотел отдать должное, где это необходимо.
Я потратил много времени, пытаясь заставить hgwebdir работать с nginx, и это немного хлопотно, потому что hgwebdir не отправляет запрос в браузер для аутентификации. В итоге я решил это так:
server {
listen 80;
listen 10240;
server_name code.zofrex.com;
access_log /home/zofrex/websites/code.zofrex.com/logs/access.log;
error_log /home/zofrex/websites/code.zofrex.com/logs/errors.log;
location / {
limit_except GET {
proxy_pass http://localhost:81;
}
fastcgi_pass 127.0.0.1:10001;
include fastcgi_params;
}
location ~ ^/(HGBot|ZeroBotAHD|zoebot|FZeroZBot|RDPrototype|RSPS3000|zerobot|rmi) {
proxy_pass http://localhost:81;
}
include defaults;
}
server {
listen 81;
access_log /home/zofrex/websites/code.zofrex.com/logs/access_secure.log;
error_log /home/zofrex/websites/code.zofrex.com/logs/errors_secure.log;
location / {
auth_basic "Restricted";
auth_basic_user_file /home/zofrex/passwords;
fastcgi_pass 127.0.0.1:10001;
include fastcgi_params;
}
include defaults;
}
На самом деле это единственный способ сделать это, поскольку limit_except нельзя комбинировать с fastcgi_pass - фактически никакие условные выражения не могут, но их можно комбинировать с proxy_pass. Понятия не имею почему.
Так, как это работает? Если поступает запрос GET, он сразу же передается в hgwebdir. Если поступает POST (т.е. push), запрос передается на прокси-сервер через порт 81, который всегда запрашивает базовую аутентификацию, тем самым обеспечивая ее выполнение.
Почему расположение с огромным регулярным выражением? Это защищенные проекты, которым я хочу требовать авторизацию даже для чтения.
Почему стоит прослушивать порт 10240? Я не могу вспомнить, почему это там.
О, и я использую wsgi с spawn-fcgi, поэтому это fastcgi_pass. Эта точная конфигурация, вероятно, вам не подойдет, но, надеюсь, тот же трюк решит ваши проблемы с толчком.
Недавно у меня была похожая проблема, и я отказался попробовать listen 81
обходной путь. Я это придумал. Я думаю, что у нас похожие проблемы, посмотрите здесь мой вопрос / ответ: Nginx не отправляет POST в бэкэнд FastCGI, но GET работает нормально?
Почему бы просто не сделать:
server {
listen 80;
listen 10240;
server_name code.zofrex.com;
access_log /home/zofrex/websites/code.zofrex.com/logs/access.log;
error_log /home/zofrex/websites/code.zofrex.com/logs/errors.log;
location / {
fastcgi_pass 127.0.0.1:10001;
include fastcgi_params;
limit_except GET HEAD {
auth_basic "Restricted";
auth_basic_user_file /home/zofrex/passwords;
}
}
location ~ ^/(HGBot|ZeroBotAHD|zoebot|FZeroZBot|RDPrototype|RSPS3000|zerobot|rmi) {
auth_basic "Restricted";
auth_basic_user_file /home/zofrex/passwords;
}
include defaults;
}
Работает с nginx 0.8.48, в более старых версиях была ошибка, когда fastcgi_pass
не был унаследован внутри блока limit_except.