Nginx Forum

Re: а проект nginx-ctpp похоже уже забросили ?

Alexandr Gomoliako — Wed, 16 May 2012 17:40:01 -0400

> Угу, и убиваете на копировании данных туда-обратно единственное преимущество

Нет, копировать тело не надо вообще, мы его спокойно передаем как
ридонли. Обратно можно тоже забрать память из скаляра и освободить в
cleanup хандлере. Оверхед будет очень маленький, но сколько
возможностей :)

> ctpp - производительность. Тесты показывают, что ctpp+nginx работает гораздо
> быстрее, чем ctpp+perl, ctpp+php и ctpp+python.

Не знаю, что там за тесты, но сравнение как минимум странное :)
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: а проект nginx-ctpp похоже уже забросили ?

Валентин Бартенев — Wed, 16 May 2012 17:22:00 -0400

On Wednesday 16 May 2012 23:06:59 Алексей Сундуков wrote:
> 16 мая 2012 г., 22:09 пользователь Валентин Бартенев написал:
> > Было бы очень странно, если бы не устраивал, учитывая, что используется
> > он в Рамблер-Почте с тех самых пор, как её начальником стал автор CTPP.
> > =)
>
> В контексте обсуждения возник такой вопрос. На сколько, чисто
> субъективно, сложно разобраться в коде ctpp и какие от него ощущения
> в контексте сапорта связанного кода (т.е. кода nginx модуля)?

Не сложно. IMHO. Парсер, генератор байткода и достаточно простая VM - это
далеко не "rocket science". Конкретно код ctpp я глубоко не копал, а с виду
вполне добротно выглядит.

--
Валентин Бартенев
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: а проект nginx-ctpp похоже уже забросили ?

Валентин Бартенев — Wed, 16 May 2012 17:20:00 -0400

On Thursday 17 May 2012 00:43:52 Alexandr Gomoliako wrote:
> > Это как? Вызывать через perl встроенный в nginx VM ctpp?
>
> Да, примерно. Мы в перл передаем тело, перл его обрабатывает и отдает
> результат. Во время обработки он может использовать хоть стпп, хоть
> любой другой шаблонизатор, их реально много на CPAN. Он также сможет
> парсить тело как JSON или как любой другой формат, нативных парсеров
> для них тоже хватает.

Угу, и убиваете на копировании данных туда-обратно единственное преимущество
ctpp - производительность. Тесты показывают, что ctpp+nginx работает гораздо
быстрее, чем ctpp+perl, ctpp+php и ctpp+python.

--
Валентин Бартенев
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Re[2]: а проект nginx-ctpp похоже уже забросили ?

Alexandr Gomoliako — Wed, 16 May 2012 16:46:01 -0400

> Это как? Вызывать через perl встроенный в nginx VM ctpp?

Да, примерно. Мы в перл передаем тело, перл его обрабатывает и отдает
результат. Во время обработки он может использовать хоть стпп, хоть
любой другой шаблонизатор, их реально много на CPAN. Он также сможет
парсить тело как JSON или как любой другой формат, нативных парсеров
для них тоже хватает.
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Re[2]: а проект nginx-ctpp похоже уже забросили ?

Алексей Сундуков — Wed, 16 May 2012 16:34:01 -0400

17 мая 2012 г., 0:16 пользователь Alexandr Gomoliako написал:
> Можно один раз сделать output filter для встроенного перла и будет
> доступно огромное количество быстрых нативных шаблонизаторов и
> парсеров любых форматов, включая стпп.

Это как? Вызывать через perl встроенный в nginx VM ctpp?
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Re[2]: а проект nginx-ctpp похоже уже забросили ?

Алексей Сундуков — Wed, 16 May 2012 16:32:00 -0400

16 мая 2012 г., 23:58 пользователь Михаил Монашёв
написал:
> Если Вы хотите форкнуться и вернуть проект к жизни, то автор ctpp
> может весьма неоднозначно отреагировать на такой шаг.

Зачем форкаться, BDS же лицензия. Напилить хотя бы для себя. Но опыта
на сях нет вообще, поэтому и думаю, стоит ли затеиваться. Тем паче
пока апдейтиться не планирую, но если перспективы туманны, то нужно
думать уже сейчас в сторону использования альтернатив либо
самостоятельной допилки.
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Re[2]: а проект nginx-ctpp похоже уже забросили ?

Alexandr Gomoliako — Wed, 16 May 2012 16:18:00 -0400

> Если Вы хотите форкнуться и вернуть проект к жизни, то автор ctpp
> может весьма неоднозначно отреагировать на такой шаг. Хотя ИМХО,
> достаточно просто править баги, а развитие проекта или заморозить или
> оставить автору, подмерживая их по мере своих сил. Со временем Вашу
> сборку/сорцы начнут везде использовать, ибо потребность в ctpp2 есть,
> а новые фичи нужны единицам.

Можно один раз сделать output filter для встроенного перла и будет
доступно огромное количество быстрых нативных шаблонизаторов и
парсеров любых форматов, включая стпп.
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: systemd and nginx custom script

Jamie Nguyen — Wed, 16 May 2012 16:06:01 -0400

On 16 May 2012 18:28, Maxim Dounin wrote:
> Hello!
>
> On Wed, May 16, 2012 at 06:01:47PM +0100, Jamie Nguyen wrote:
>
>> Hi, I am co-maintainer for nginx Fedora package. We would like to
>> upstream our systemd service file. Could you consider including it in
>> the nginx tarball?
>
> We don't usually include any init scripts in distribution and
> usually rely on package mainterners to provide one appropriate for
> a system in question.

No problem.

> If you think the file will be usable for ones who compile
> nginx from source, you may place it here on wiki:
>
> http://wiki.nginx.org/InitScripts

Good idea. Done!: http://wiki.nginx.org/FedoraSystemdServiceFile

>> ExecReload=/usr/sbin/nginx -s reload
>> ExecStop=/usr/sbin/nginx -s quit
>
> Just a side note: using "-s ..." on unix might not be a good idea,
> as it needs nginx binary compatible to one already running to be
> able to parse config for a pid file name and sent appropriate
> signal. It was introduced mainly for Windows. On unix-like
> systems it's more fail-safe to explicitly send appropriate
> signals.

No problem. I've changed it to:

ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s QUIT $MAINPID

> Just a side note 2: your service file obviously rely on
> non-default configure arguments, you may want to explicitly state
> this when placing it on wiki (or change the file to match
> defaults).

I've added a comment in the wiki page.

Thanks very much for your advice :-)

Kind regards,
Jamie

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re[2]: а проект nginx-ctpp похоже уже забросили ?

Михаил Монашёв — Wed, 16 May 2012 16:00:00 -0400

Здравствуйте, Алексей.

>> Было бы очень странно, если бы не устраивал, учитывая, что
>> используется он в Рамблер-Почте с тех самых пор, как её начальником
>> стал автор CTPP. =)

> В контексте обсуждения возник такой вопрос. На сколько, чисто
> субъективно, сложно разобраться в коде ctpp и какие от него ощущения
> в контексте сапорта связанного кода (т.е. кода nginx модуля)?

Если Вы хотите форкнуться и вернуть проект к жизни, то автор ctpp
может весьма неоднозначно отреагировать на такой шаг. Хотя ИМХО,
достаточно просто править баги, а развитие проекта или заморозить или
оставить автору, подмерживая их по мере своих сил. Со временем Вашу
сборку/сорцы начнут везде использовать, ибо потребность в ctpp2 есть,
а новые фичи нужны единицам.

--
С уважением,
Михаил mailto:postmaster@softsearch.ru

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: а проект nginx-ctpp похоже уже забросили ?

Andrey Velikoredchanin — Wed, 16 May 2012 15:54:01 -0400

16 мая 2012 г., 23:06 пользователь Алексей Сундуков

написал:

>
> В контексте обсуждения возник такой вопрос. На сколько, чисто
> субъективно, сложно разобраться в коде ctpp и какие от него ощущения
> в контексте сапорта связанного кода (т.е. кода nginx модуля)?
>
> Могу сказать свое субъективное мнение о ctpp модуле для nginx. Когда о нем
узнал, смотрел его код и не нашел в нем чего-то сильно сложного. Но т.к.
интерес был чисто академический, дальше изучения дело не пошло. Тем не
менее, считаю что переделать его под новые версии nginx не должно
представлять особой сложности. Было-бы желание.
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re[2]: а проект nginx-ctpp похоже уже забросили ?

Михаил Монашёв — Wed, 16 May 2012 15:48:01 -0400

Здравствуйте, Валентин.

> Скажем так, сей "проект" имеет у меня сейчас очень низкий приоритет.
> Отчасти и потому, что перспективы CTPP в целом очень туманны.

А в чём туманность? Баги или не развивается?

--
С уважением,
Михаил mailto:postmaster@softsearch.ru

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: а проект nginx-ctpp похоже уже забросили ?

Алексей Сундуков — Wed, 16 May 2012 15:08:00 -0400

16 мая 2012 г., 22:09 пользователь Валентин Бартенев написал:
> Было бы очень странно, если бы не устраивал, учитывая, что используется он в
> Рамблер-Почте с тех самых пор, как её начальником стал автор CTPP. =)

В контексте обсуждения возник такой вопрос. На сколько, чисто
субъективно, сложно разобраться в коде ctpp и какие от него ощущения
в контексте сапорта связанного кода (т.е. кода nginx модуля)?
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

статика по HTTPS не даёт 304 Not Modified

ha.ppy.neko — Wed, 16 May 2012 14:30:00 -0400

Добрый день.

Задача: отдавать nginx'ом статичные html файлы по HTTPS так, чтобы
браузер максимально долго их кэшировал.

Делаю простейший конфиг:

location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|pdf|ppt|txt|bmp|rtf|js|html)$ {
root /www/test;
add_header Cache-Control public;
expires max;
}

и в случае HTTP получаю ожидаемый результат: первый запрос от браузера
200 OK со страницей, на последующие обновления страницы 304 Not
Modified от nginx'а. Стоит только включить HTTPS (ssl on;) как после
каждого рефреша получаю в ответ 200 OK вместе со всей страницей.
Проверял в chrome.

Подскажите, куда смотреть?
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: а проект nginx-ctpp похоже уже забросили ?

Валентин Бартенев — Wed, 16 May 2012 14:10:01 -0400

On Wednesday 16 May 2012 21:54:00 Алексей Сундуков wrote:
> 16 мая 2012 г., 20:50 пользователь Валентин Бартенев написал:
> > On Wednesday 16 May 2012 20:12:51 Алексей Сундуков wrote:
> >> 16 мая 2012 г., 18:32 пользователь Валентин Бартенев написал:
> > Сообщества вокруг CTPP практически нету, хотя у проекта уже солидный
> > возраст.
>
> Как я понимаю движок в текущем виде используется где-то в недрах
> рамблера и их полностью устраивает.

Было бы очень странно, если бы не устраивал, учитывая, что используется он в
Рамблер-Почте с тех самых пор, как её начальником стал автор CTPP. =)

--
Валентин Бартенев
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: а проект nginx-ctpp похоже уже забросили ?

Алексей Сундуков — Wed, 16 May 2012 13:56:01 -0400

16 мая 2012 г., 20:50 пользователь Валентин Бартенев написал:
> On Wednesday 16 May 2012 20:12:51 Алексей Сундуков wrote:
>> 16 мая 2012 г., 18:32 пользователь Валентин Бартенев написал:

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

Как я понимаю движок в текущем виде используется где-то в недрах
рамблера и их полностью устраивает. Хотя было бы любопытно узнать в
каком количестве проектов он используется вне означенной компании. Мне
вот движок с модулей очень понравился и я его в своем движке
использую, но у меня nginx старых версий. В таком контексте дальнейшее
его использование конечно становится туманным. Но чем заменить если,
вопрос. На вскидку думается в сторону XSLT, но опыт подсказывает, что
работать будет медленнее, а ресурсов ржать больше. Но как профит от
такой схемы довольно заманчиво выглядит возможность использования
клиентского XSLT.

Ни кто не пытался сравнивать сравнивать вариант работы с
использованием ctpp против xslt?
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: systemd and nginx custom script

Maxim Dounin — Wed, 16 May 2012 13:30:00 -0400

Hello!

On Wed, May 16, 2012 at 06:01:47PM +0100, Jamie Nguyen wrote:

> Hi, I am co-maintainer for nginx Fedora package. We would like to
> upstream our systemd service file. Could you consider including it in
> the nginx tarball?

We don't usually include any init scripts in distribution and
usually rely on package mainterners to provide one appropriate for
a system in question.

If you think the file will be usable for ones who compile
nginx from source, you may place it here on wiki:

http://wiki.nginx.org/InitScripts

[...]

> ExecReload=/usr/sbin/nginx -s reload
> ExecStop=/usr/sbin/nginx -s quit

Just a side note: using "-s ..." on unix might not be a good idea,
as it needs nginx binary compatible to one already running to be
able to parse config for a pid file name and sent appropriate
signal. It was introduced mainly for Windows. On unix-like
systems it's more fail-safe to explicitly send appropriate
signals.

Just a side note 2: your service file obviously rely on
non-default configure arguments, you may want to explicitly state
this when placing it on wiki (or change the file to match
defaults).

Maxim Dounin

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: а проект nginx-ctpp похоже уже забросили ?

Dmitry — Wed, 16 May 2012 13:10:00 -0400

В разрезе интеграции судить не возьмусь, но собирается и не сбоит в
редхатовской ветке сырцами легко, мягко и не ремурсоемко.

Но теперь суть туманности стала понятной. Спасибо.
16.05.2012 20:50 пользователь "Валентин Бартенев" написал:

> On Wednesday 16 May 2012 20:12:51 Алексей Сундуков wrote:
> > 16 мая 2012 г., 18:32 пользователь Валентин Бартенев
> написал:
> > > Отчасти и потому, что перспективы CTPP в целом очень туманны.
> >
> > В каком контексте? Ну т.е. это вопрос "туманны лично для меня, занят
> > другим" или "туманны проекта в целом вообще" или же "есть более
> > удачные решения"? Там конечно есть некоторые моменты с которыми на
> > практике возникли проблемы, но в целом лично мне идея данного
> > шаблонизатора кажется интересной.
>
> Туманны в плане поддержки проекта CTPP самим автором. Документация давным
> давно заброшена, сборка регулярно ломается. Я сделал попытку разобраться с
> этим багом когда только появился тикет, но не смог собрать на своей системе
> ни одну из последних версий CTPP. И это происходит уже неоднократно.
> Предыдущие
> разы я чинил и слал автору патчи, но сколько можно. Вероятно это одна из
> причин
> отсутствия шаблонизатора в официальных репозиториях многих дистрибутивов.
> Сообщества вокруг CTPP практически нету, хотя у проекта уже солидный
> возраст.
> Jinja2 и то куда моложе.
>
> --
> Валентин Бартенев
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

systemd and nginx custom script

Jamie Nguyen — Wed, 16 May 2012 13:02:01 -0400

Hi, I am co-maintainer for nginx Fedora package. We would like to
upstream our systemd service file. Could you consider including it in
the nginx tarball?

In other projects (e.g. rsyslog, mpd) the service file is only
installed if "--with-systemdsystemunitdir=/usr/lib/systemd/system" was
passed to the configure script. The service file we currently use
should work universally across systems using systemd:

$ cat /lib/systemd/system/nginx.service
[Unit]
Description=A high performance web server and reverse proxy server
After=syslog.target network.target remote-fs.target nss-lookup.target

[Service]
Type=forking
PIDFile=/run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t
ExecStart=/usr/sbin/nginx
ExecReload=/usr/sbin/nginx -s reload
ExecStop=/usr/sbin/nginx -s quit
PrivateTmp=true

[Install]
WantedBy=multi-user.target

Most distributions implement a "zero-downtime upgrade" option in their
initscript. This cannot currently be implemented in systemd, so I
implemented it in a separate script. I paste the script below for
possible inclusion in http://wiki.nginx.org/CommandLine (Perhaps you
might even consider including this script (or something similar) in
the nginx tarball as it would be helpful for systems using systemd.)

#!/bin/sh
[ ! -f /run/nginx.pid ] && exit 1
echo "Start new nginx master..."
/bin/systemctl kill --signal=USR2 nginx.service
sleep 5
[ ! -f /run/nginx.pid.oldbin ] && sleep 5
if [ ! -f /run/nginx.pid.oldbin ]; then
echo "Failed to start new nginx master."
exit 1
fi
echo "Stop old nginx master gracefully..."
oldpid=`cat /run/nginx.pid.oldbin 2>/dev/null`
/bin/kill -s QUIT $oldpid 2>/dev/null

Kind regards,
Jamie

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: а проект nginx-ctpp похоже уже забросили ?

Валентин Бартенев — Wed, 16 May 2012 12:52:01 -0400

On Wednesday 16 May 2012 20:12:51 Алексей Сундуков wrote:
> 16 мая 2012 г., 18:32 пользователь Валентин Бартенев написал:
> > Отчасти и потому, что перспективы CTPP в целом очень туманны.
>
> В каком контексте? Ну т.е. это вопрос "туманны лично для меня, занят
> другим" или "туманны проекта в целом вообще" или же "есть более
> удачные решения"? Там конечно есть некоторые моменты с которыми на
> практике возникли проблемы, но в целом лично мне идея данного
> шаблонизатора кажется интересной.

Туманны в плане поддержки проекта CTPP самим автором. Документация давным
давно заброшена, сборка регулярно ломается. Я сделал попытку разобраться с
этим багом когда только появился тикет, но не смог собрать на своей системе
ни одну из последних версий CTPP. И это происходит уже неоднократно. Предыдущие
разы я чинил и слал автору патчи, но сколько можно. Вероятно это одна из причин
отсутствия шаблонизатора в официальных репозиториях многих дистрибутивов.
Сообщества вокруг CTPP практически нету, хотя у проекта уже солидный возраст.
Jinja2 и то куда моложе.

--
Валентин Бартенев
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Best way to handle preprod server_names

B.R. — Wed, 16 May 2012 12:50:01 -0400

Hello,

Typically, I would use one directory per host to serve content from each
domain and use one config file per generic type:
http {
listen 80;
root /var/www/$host;

server { # Include that section from a separate file
server_name ~^[[:alnum:]]+(\.[[:alnum:]]+
)*\.preprod\.domain[0-9]*\.com$;
# Pre-production rules
}

server { # Include that section from a separate file
server_name ~^[[:alnum:]]+(\.[[:alnum:]]+)*(!\.preprod)\.domain[0-9]*
\.com$;
# Production rules
}
}

You can then create server bloc listening to specific subdomains for
particular case, i.e.:
server {
server_name test.preprod.domain42.com;
# Rules here have higher priority than the generic rules since the
server_name uses an exact match comparison
}

You will have to work further on regex to be sure they do what you want
them to do. ;o)
---
*B. R.*

On Wed, May 16, 2012 at 5:08 AM, Greg wrote:

> Hi,
>
> I'm going to migrate a lots of vhosts from Squid+Apache2 to NginX, step by
> step.
> First step is to migrate just NginX and few static vhosts.
>
> Actually there is ~600 domains x 5 vhosts + equivalent for preprod. So I
> wrote a NginX vhost for ".mydomain1.com .mydomain2.com" and so on with
> the 600 domains.
>
> Question is, how the best practices to have this domains for our preprod
> which looks like ".preprod.mydomain1.com" for each domains.
>
> Preprod has specific config like gzip disabled (for internals purpose...).
>
> Actually, prod's config looks like :
> server {
> server_name .mydomain1.com; # main domain
> include /etc/nginx/domains.conf;
> server_name_in_redirect off;
> include common/prod.conf
> }
>
> And domains.conf :
> server_name
> .mydomain1.com
> .mydomain2.com
> ...
> ;
>
> Preprod could have this config :
> server {
> server_name .preprod.mydomain1.com; # main domain
> include
> /etc/nginx/preprod_domains.conf;
> server_name_in_redirect off;
> include common/preprod.conf
> }
>
> Which means (600 x 5 x 2) vhosts...
>
> Is there a better way ?
>
> --
> Greg
>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: а проект nginx-ctpp похоже уже забросили ?

Dmitry — Wed, 16 May 2012 12:28:00 -0400

А действительно, в чем туманность? Шаблонизатор не выглядит перегруженым
логикой, подразумевает копирование, написан на cpp, не берет на себя
больше, чем на самом деле нужно от view-level и легко интересуется в
проекты, не навязывая общую платформу. Аналоги? Блитц, увы, перегружен
программированием. Что еще, как альтернатива?
16.05.2012 20:13 пользователь "Алексей Сундуков"
написал:

> 16 мая 2012 г., 18:32 пользователь Валентин Бартенев
> написал:
> > Отчасти и потому, что перспективы CTPP в целом очень туманны.
>
> В каком контексте? Ну т.е. это вопрос "туманны лично для меня, занят
> другим" или "туманны проекта в целом вообще" или же "есть более
> удачные решения"? Там конечно есть некоторые моменты с которыми на
> практике возникли проблемы, но в целом лично мне идея данного
> шаблонизатора кажется интересной.
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: а проект nginx-ctpp похоже уже забросили ?

Алексей Сундуков — Wed, 16 May 2012 12:14:00 -0400

16 мая 2012 г., 18:32 пользователь Валентин Бартенев написал:
> Отчасти и потому, что перспективы CTPP в целом очень туманны.

В каком контексте? Ну т.е. это вопрос "туманны лично для меня, занят
другим" или "туманны проекта в целом вообще" или же "есть более
удачные решения"? Там конечно есть некоторые моменты с которыми на
практике возникли проблемы, но в целом лично мне идея данного
шаблонизатора кажется интересной.
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: а проект nginx-ctpp похоже уже забросили ?

Валентин Бартенев — Wed, 16 May 2012 11:08:01 -0400

On Wednesday 16 May 2012 18:41:54 Sergey Kobzar wrote:
> On 05/16/12 17:32, Валентин Бартенев wrote:
> > On Wednesday 16 May 2012 15:01:52 Ivan wrote:
> >> под последний стабильный nginx 1.2 не собирается, баг-трекер
> >> https://dev.vbart.ru/issues/22 не работает ...
> >
> > Скажем так, сей "проект" имеет у меня сейчас очень низкий приоритет.
> > Отчасти и потому, что перспективы CTPP в целом очень туманны.
> >
> > p.s. А за неработающий баг-трекер спасибо мейнтейнерам портов freebsd,
> > сломали redmine еще в январе и так до сих пор не починили. Откатывать
> > обратно весь rubygems мне было не к спеху, решил подождать пока починят
> > и ожидание затянулось уже на полгода.
>
> А с какой на какую версию переходили? Я помнится с 1.3 на 1.4 пытался
> переехать - столько граблей отгреб, что в конечном итоге вернул все взад.
>

Я точно не помню, я граблей огреб обновив всякие руби-пакетики по зависимостям,
а версия самого redmine была по-моему еще 1.2.x, может быть уже 1.3. Полдня убил
на выяснение, почему оно не работает, а несколько дней спустя порт redmine
просто пометили как broken, и до сих пор он в таком состоянии находится.

В общем-то оно не важно, давайте на этом закончим оффтопить.

--
Валентин Бартенев
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: а проект nginx-ctpp похоже уже забросили ?

sergey.kobzar — Wed, 16 May 2012 10:42:00 -0400

On 05/16/12 17:32, Валентин Бартенев wrote:
> On Wednesday 16 May 2012 15:01:52 Ivan wrote:
>> под последний стабильный nginx 1.2 не собирается, баг-трекер
>> https://dev.vbart.ru/issues/22 не работает ...
>
> Скажем так, сей "проект" имеет у меня сейчас очень низкий приоритет.
> Отчасти и потому, что перспективы CTPP в целом очень туманны.
>
> p.s. А за неработающий баг-трекер спасибо мейнтейнерам портов freebsd, сломали
> redmine еще в январе и так до сих пор не починили. Откатывать обратно весь
> rubygems мне было не к спеху, решил подождать пока починят и ожидание
> затянулось уже на полгода.

А с какой на какую версию переходили? Я помнится с 1.3 на 1.4 пытался
переехать - столько граблей отгреб, что в конечном итоге вернул все взад.

>
> --
> Валентин Бартенев
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: а проект nginx-ctpp похоже уже забросили ?

Валентин Бартенев — Wed, 16 May 2012 10:34:00 -0400

On Wednesday 16 May 2012 15:01:52 Ivan wrote:
> под последний стабильный nginx 1.2 не собирается, баг-трекер
> https://dev.vbart.ru/issues/22 не работает ...

Скажем так, сей "проект" имеет у меня сейчас очень низкий приоритет.
Отчасти и потому, что перспективы CTPP в целом очень туманны.

p.s. А за неработающий баг-трекер спасибо мейнтейнерам портов freebsd, сломали
redmine еще в январе и так до сих пор не починили. Откатывать обратно весь
rubygems мне было не к спеху, решил подождать пока починят и ожидание
затянулось уже на полгода.

--
Валентин Бартенев
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: а проект nginx-ctpp похоже уже забросили ?

Алексей Сундуков — Wed, 16 May 2012 10:22:00 -0400

Ну как вариант можно временно от nginx отвязаться перейдя на
использование компонент идущих с ctpp. Я лично в работе в рамках
одного проекта использую как nginx модуль, так и отдельный php
extension. Если не ошибаюсь, то всегда остается вариант формирования
JSON с данными и отправка их в VM ctpp в командной строке. Сейчас
работать с JSON можно практически в любых языка.

16 мая 2012 г., 15:01 пользователь Ivan написал:
>
> под последний стабильный nginx 1.2 не собирается, баг-трекер https://dev.vbart.ru/issues/22 не работает ...
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx 1.2: static file truncated with HTTP status code 200

Maxim Dounin — Wed, 16 May 2012 10:18:01 -0400

Hello!

On Wed, May 16, 2012 at 09:40:37AM -0400, mengqy wrote:

> We've been running nginx 1.1.18, 1.1.19, 1.2.0, with both HTTP/HTTPS
> enabled. Our static files are loaded from nginx root, but since 1.1.18
> $request_time of static files some times gets 10+ seconds, recardless
> the actual file size. Various optimizing were tried with little gain,
> and the problem seems irrelavent to browsers as of access log. With

The $request_time variable includes request reading times, as well
as request sending times. It may be big even for relatively small
files if client is slow (and/or just silently gone without closing
connection).

> 1.2.0 we just noticed that access log shows file truncating with HTTP
> status code 200. Looking forward to your help, thank you.

Size recorded in $body_bytes_sent / $bytes_sent represents actuall
data size sent to a socket, not a real file size. I.e. if transfer
is aborted, e.g. due to timeout and/or connection close by a
client, it will be smaller than real file size (as long as file is
bigger than socket's send buffer).

Status code will still be 200 as it represents status sent to
client.

>
> ------------------
> Log format:
> ------------------
>
> log_format main '$remote_addr - $remote_user [$time_local]
> [$request_time] [$upstream_response_time] "$request" $request_length ' '
> $status $upstream_addr $body_bytes_sent "$http_referer" '
> '"$http_user_agent" "$http_x_forwarded_for"';
>
> ---------------------
> access log:
> ---------------------
>
> 27.129.164.208 - - [16/May/2012:06:44:12 +0800] [15.511] [-] "GET
> /mgt/images/v3/common/f4.gif?v=6 HTTP/1.1" 950 200 - 57756
> "http://x.x.x/mgt/frame.jsp?url=RA9" "Mozilla/4.0 (compatible; MSIE 6.0;
> Windows NT 5.1; SV1; .NET CLR 2.0.50727; 360SE)" "-"
> 27.129.164.208 - - [16/May/2012:06:45:33 +0800] [11.194] [-] "GET
> /mgt/images/v3/common/f4.gif?v=6 HTTP/1.1" 950 200 - 106455
> "http://x.x.x/mgt/frame.jsp?url=RA9" "Mozilla/4.0 (compatible; MSIE 6.0;
> Windows NT 5.1; SV1; .NET CLR 2.0.50727; 360SE)" "-"
>
> $ ls -l /var/www/html/mgt/mgt/images/v3/common/f4.gif
> -rw-r--r-- 1 root root 106455 2012-04-20 23:09
> /var/www/html/mgt/mgt/images/v3/common/f4.gif
>
> Actual file size is 106455 bytes, yet the first log shows 57756 bytes.

This is usually just means that client wasn't able to get full
response for some reason, see above. In your case it looks like
send_timeout was triggered, as it's set 10 seconds in your config.
(Just a side note: client timeouts are logged at "info" level to
error log.)

This may be a result of some problem in nginx, but highly
unlikely. I would rather suggest it's network connectivity
problems either on your side or on the client's side.

[...]

Maxim Dounin

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: nginx 1.2: static file truncated with HTTP status code 200

Joshua Zhu — Wed, 16 May 2012 09:52:00 -0400

Hi,

On Wed, May 16, 2012 at 9:40 PM, mengqy wrote:

> We've been running nginx 1.1.18, 1.1.19, 1.2.0, with both HTTP/HTTPS
> enabled. Our static files are loaded from nginx root, but since 1.1.18
> $request_time of static files some times gets 10+ seconds, recardless
> the actual file size. Various optimizing were tried with little gain,
> and the problem seems irrelavent to browsers as of access log. With
> 1.2.0 we just noticed that access log shows file truncating with HTTP
> status code 200. Looking forward to your help, thank you.
>

Why do you think the file was truncated by Nginx? There're other reasons
which might cause $body_bytes_sent less than the real size of the file. For
instance, it can be true when the client closes the connection before
downloading the file completely.

Regards,

--
Joshua Zhu
Senior Software Engineer
Server Platforms Team at Taobao
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

nginx 1.2: static file truncated with HTTP status code 200

mengqy — Wed, 16 May 2012 09:40:37 -0400

We've been running nginx 1.1.18, 1.1.19, 1.2.0, with both HTTP/HTTPS enabled. Our static files are loaded from nginx root, but since 1.1.18 $request_time of static files some times gets 10+ seconds, recardless the actual file size. Various optimizing were tried with little gain, and the problem seems irrelavent to browsers as of access log. With 1.2.0 we just noticed that access log shows file truncating with HTTP status code 200. Looking forward to your help, thank you.

------------------
Log format:
------------------

log_format main '$remote_addr - $remote_user [$time_local] [$request_time] [$upstream_response_time] "$request" $request_length ' ' $status $upstream_addr $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"';

---------------------
access log:
---------------------

27.129.164.208 - - [16/May/2012:06:44:12 +0800] [15.511] [-] "GET /mgt/images/v3/common/f4.gif?v=6 HTTP/1.1" 950 200 - 57756 "http://x.x.x/mgt/frame.jsp?url=RA9" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; 360SE)" "-"
27.129.164.208 - - [16/May/2012:06:45:33 +0800] [11.194] [-] "GET /mgt/images/v3/common/f4.gif?v=6 HTTP/1.1" 950 200 - 106455 "http://x.x.x/mgt/frame.jsp?url=RA9" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; 360SE)" "-"

$ ls -l /var/www/html/mgt/mgt/images/v3/common/f4.gif
-rw-r--r-- 1 root root 106455 2012-04-20 23:09 /var/www/html/mgt/mgt/images/v3/common/f4.gif

Actual file size is 106455 bytes, yet the first log shows 57756 bytes.

-----------------
System info:
-----------------

$ uname -a
Linux debian 2.6.26-1-amd64 #1 SMP Sat Jan 10 17:57:00 UTC 2009 x86_64 GNU/Linux

CPU: Intel(R) Xeon(TM) CPU 3.00GHz * 2, 8 cores.

$ nginx -V
nginx version: nginx/1.2.0
built by gcc 4.3.2 (Debian 4.3.2-1.1)
TLS SNI support enabled
configure arguments: --prefix=/usr/local/nginx --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx --user=www-data --group=www-data --with-http_ssl_module --with-cpu-opt=CPU --with-http_stub_status_module --with-pcre --add-module=../nginx-sticky-module-1.0

-----------------------
nginx.conf:
-----------------------

user www-data www-data;
worker_processes 16;
error_log /var/log/nginx/error.log error;
pid logs/nginx.pid;
worker_rlimit_nofile 65535;

events {
use epoll;
worker_connections 4096;
epoll_events 1024;
accept_mutex off;
}
http {
include mime.types;
default_type application/octet-stream;
charset utf-8;

server_names_hash_bucket_size 128;
client_header_buffer_size 32k;
large_client_header_buffers 4 32k;

client_max_body_size 300m;
client_body_buffer_size 512k;

open_file_cache max=10000 inactive=300s;
open_file_cache_valid 300s;
open_file_cache_min_uses 1;
open_file_cache_errors on;

gzip on;
gzip_min_length 1k;
gzip_buffers 4 16k;
gzip_http_version 1.1;
gzip_comp_level 2;
gzip_types text/plain application/x-javascript text/css application/xml;
gzip_vary on;

log_format main '$remote_addr - $remote_user [$time_local] [$request_time] [$upstream_response_time] "$request" $request_length ' ' $status $upstream_addr $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"';

access_log /var/log/nginx/access.log main;

sendfile on;
tcp_nopush on;
tcp_nodelay on;

upstream mgt_tomcats {
sticky path=/;
server 192.168.0.40:8080 max_fails=2 fail_timeout=60s;
server 192.168.0.45:8080 max_fails=2 fail_timeout=60s;
keepalive 64;
}

server {
listen x.x.x.x:80;
include common.conf
}

server {
listen x.x.x.x:443;
ssl on;
ssl_certificate server.crt;
ssl_certificate_key server.key;

ssl_session_timeout 5m;
ssl_session_cache shared:SSL:10m;

ssl_protocols SSLv2 SSLv3 TLSv1;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;

include common.conf

# snip, snip, other configurations
}
}
----------------------
common.conf:
----------------------
keepalive_timeout 10;

server_name x.x.x;
root /var/www/html/mgt;

proxy_connect_timeout 60;
proxy_read_timeout 60;
proxy_send_timeout 10;
proxy_buffer_size 16k;
proxy_buffers 4 64k;
proxy_busy_buffers_size 128k;

proxy_http_version 1.1;
proxy_set_header Connection "";

proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass_header User-Agent;

location ~* ^/(mgt|Apps|mgt-system)/(image|styles|scripts)/ {
expires 30d;
if (!-e $request_filename) {
proxy_pass http://mgt_tomcats;
break;
}
}

[nginx] svn commit: r4638 - in trunk/src/http: . modules

Anonymous User — Wed, 16 May 2012 09:28:01 -0400

Author: ru
Date: 2012-05-16 13:27:04 +0000 (Wed, 16 May 2012)
New Revision: 4638
URL: http://trac.nginx.org/nginx/changeset/4638/nginx

Log:
Zero padded the returned and logged HTTP status code, and fixed possible
buffer overrun in $status handling.

Modified:
trunk/src/http/modules/ngx_http_log_module.c
trunk/src/http/ngx_http_header_filter_module.c

Modified: trunk/src/http/modules/ngx_http_log_module.c
===================================================================
--- trunk/src/http/modules/ngx_http_log_module.c 2012-05-16 13:22:03 UTC (rev 4637)
+++ trunk/src/http/modules/ngx_http_log_module.c 2012-05-16 13:27:04 UTC (rev 4638)
@@ -205,7 +205,7 @@
{ ngx_string("msec"), NGX_TIME_T_LEN + 4, ngx_http_log_msec },
{ ngx_string("request_time"), NGX_TIME_T_LEN + 4,
ngx_http_log_request_time },
- { ngx_string("status"), 3, ngx_http_log_status },
+ { ngx_string("status"), NGX_INT_T_LEN, ngx_http_log_status },
{ ngx_string("bytes_sent"), NGX_OFF_T_LEN, ngx_http_log_bytes_sent },
{ ngx_string("body_bytes_sent"), NGX_OFF_T_LEN,
ngx_http_log_body_bytes_sent },
@@ -593,7 +593,7 @@
status = 0;
}

- return ngx_sprintf(buf, "%ui", status);
+ return ngx_sprintf(buf, "%03ui", status);
}

Modified: trunk/src/http/ngx_http_header_filter_module.c
===================================================================
--- trunk/src/http/ngx_http_header_filter_module.c 2012-05-16 13:22:03 UTC (rev 4637)
+++ trunk/src/http/ngx_http_header_filter_module.c 2012-05-16 13:27:04 UTC (rev 4638)
@@ -445,7 +445,7 @@
b->last = ngx_copy(b->last, status_line->data, status_line->len);

} else {
- b->last = ngx_sprintf(b->last, "%ui", status);
+ b->last = ngx_sprintf(b->last, "%03ui", status);
}
*b->last++ = CR; *b->last++ = LF;

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel