Re: Sending nginx errors to syslog but fuser -u still shows error file open by nginx

[CJ Ess]

Ok, I understand what is happening now, thank you!


On Wed, Apr 20, 2016 at 11:52 AM, Maxim Dounin  wrote:

> Hello!
>
> On Wed, Apr 20, 2016 at 09:24:52AM -0400, CJ Ess wrote:
>
> > I've tried putting this directive into the nginx config file in both the
> > main and html sections:
> >
> > error_log syslog:server=127.0.0.1,facility=local5 error;
> >
> > The file tests fine and reloads without issue, however if I do fuser -u
> on
> > the error file (which is the same one used by syslog) I see that every
> > nginx process has it open. Is there anyway to be sure that errors are
> being
> > written by syslog and not the nginx process itself?
>
> At least one file-based error log must be present.  In particular,
> it is used to redirect STDERR (as in some cases written to by
> various libraries), and it is also believed to be useful to log
> errors of writing to syslog when they happen.  If no file-based
> logs are configured, a compiled-in default one will be used.
>
> --
> Maxim Dounin
> http://nginx.org/
>
> ___
> 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: (52) Empty reply from server

[Francis Daly]

On Wed, Apr 20, 2016 at 12:54:13PM +0530, Pankaj Chaudhary wrote:

Hi there,

> >>But your code snippet does not match exactly the types and return values
> >>of that example. I don't know if that is something worth investigating.
> 
> I have tried to change match exactly the types and return values
> of that example. but below is response curl: (52) Empty reply from server

> ngx_int_tset_custom_header_in_headers_out(ngx_http_request_t *r,
> ngx_str_t *key, ngx_str_t *value) {


The code snippet you show seems to relate to writing your own http
headers.

> below is "curl -i" response
> 
> HTTP/1.1 200 OK
> Server: nginx/1.9.12
> Date: Wed, 20 Apr 2016 15:25:20 GMT
> Content-Type: text/plain
> Content-Length: 14
> Connection: keep-alive
> cookie: thisitestvalue
> user_agent: 10.9 user
> get-rese: Cookie

The "curl" output you show seems to show your own http headers being
successfully written.

So it looks like what you have shown, is working.

That's good.

f
-- 
Francis Dalyfran...@daoine.org

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

Re: Making Tomcat accessible only through nginx reverse proxy

[Francis Daly]

On Wed, Apr 20, 2016 at 07:19:55AM -0400, gischethans wrote:

Hi there,

> I have a Tomcat server serving a web application and I have a Nginx server
> running in front of it as a reverse proxy.

What you need is that your users talk to nginx, and that nginx is able
to talk to tomcat.

What you additionally want, is that your users do not talk to tomcat.

All of that network setup is outside of anything that nginx can do.

> In order to prevent Tomcat from listening to other IPs, I added
> "address=127.0.0.1" to the connector configuration.

That will mean that your users cannot talk to tomcat (unless you do
something special to allow them to).

It will also mean that nginx cannot talk to tomcat, unless you do
something special to allow it to.

The easiest special thing is probably to run nginx on the same server
as tomcat.

If that is not what you want, then you will probably need some firewalling
/ ip forwarding on the tomcat machine to allow nginx connect to something
which gets sent to tomcat.

(But at that point, it may be easier to just leave tomcat listening on
the public address, and add firewalling to block anything other than
nginx from accessing it.)

> In the Nginx server, I have these lines for the server configuration.

On the nginx side, what you have looks fine. In the "proxy_pass" line, it
will probably be simpler if you use the IP:port that tomcat is listening
on (that nginx can connect to) rather than the hostname.

> Now, if I try to use the FQDN to access the web application, Chrome reports
> ERR_CONNECTION_REFUSED. My Nginx configuration seems to be the culprit based
> on what I understood. How can it be corrected?

I suspect that your request to the FQDN does not get to nginx. After
you have things configured correctly, changing name resolution (dns)
so that the FQDN corresponds to the nginx IP address instead of the
tomcat IP address will be a necessary step.

Good luck with it,

f
-- 
Francis Dalyfran...@daoine.org

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

Re: Sending nginx errors to syslog but fuser -u still shows error file open by nginx

[Maxim Dounin]

Hello!

On Wed, Apr 20, 2016 at 09:24:52AM -0400, CJ Ess wrote:

> I've tried putting this directive into the nginx config file in both the
> main and html sections:
> 
> error_log syslog:server=127.0.0.1,facility=local5 error;
> 
> The file tests fine and reloads without issue, however if I do fuser -u on
> the error file (which is the same one used by syslog) I see that every
> nginx process has it open. Is there anyway to be sure that errors are being
> written by syslog and not the nginx process itself?

At least one file-based error log must be present.  In particular, 
it is used to redirect STDERR (as in some cases written to by 
various libraries), and it is also believed to be useful to log 
errors of writing to syslog when they happen.  If no file-based 
logs are configured, a compiled-in default one will be used.

-- 
Maxim Dounin
http://nginx.org/

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

Re: Sending nginx errors to syslog but fuser -u still shows error file open by nginx

[CJ Ess]

Yes, I went as far as to stop nginx altogether, manually verify there are
no nginx processes running, then start it again and it opens the error log
first thing.

On Wed, Apr 20, 2016 at 9:51 AM, Robert Paprocki <
rpapro...@fearnothingproductions.net> wrote:

> Have you done a full restart (not a reload)? I would imagine the master
> process needs to flush everything out.
>
> > On Apr 20, 2016, at 06:24, CJ Ess  wrote:
> >
> > I've tried putting this directive into the nginx config file in both the
> main and html sections:
> >
> > error_log syslog:server=127.0.0.1,facility=local5 error;
> >
> > The file tests fine and reloads without issue, however if I do fuser -u
> on the error file (which is the same one used by syslog) I see that every
> nginx process has it open. Is there anyway to be sure that errors are being
> written by syslog and not the nginx process itself?
> >
> >
> > ___
> > 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
>
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: 3rd party modules requiring ngx_http_postpone_filter_module

[Maxim Dounin]

Hello!

On Wed, Apr 20, 2016 at 12:33:17AM -0400, Anthony Ryan wrote:

> Hello,
> 
> I'm currently looking for ideas to resolve a 3rd party module
> regression[1][2] that I keep running into, and figured it would be
> best to consult the experts.
> 
> The ngx_http_postpone_filter_module is a critical helper for many
> modules to ensure subrequests are properly ordered. But I can't seem
> to find a proper way to ensure it's included for a 3rd party module.
> 
> All of the internal modules which use it have a special declaration in
> the auto/modules file enabling postpone, but among the 3rd party
> modules there has only ever been crappy workarounds (documentation
> saying to enable the SSI module or another which pulls in postpone) or
> hacks to add HTTP_POSTPONE_FILTER_SRCS to HTTP_SRCS.

I personally think that documenting that SSI module should not be 
excluded from a build is good enough approach for all practical 
reasons.

Hacks that use HTTP_POSTPONE_FILTER_SRCS are certainly hacks and 
they were expected to fail sooner or later.

[...]

-- 
Maxim Dounin
http://nginx.org/

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

Sending nginx errors to syslog but fuser -u still shows error file open by nginx

[CJ Ess]

I've tried putting this directive into the nginx config file in both the
main and html sections:

error_log syslog:server=127.0.0.1,facility=local5 error;

The file tests fine and reloads without issue, however if I do fuser -u on
the error file (which is the same one used by syslog) I see that every
nginx process has it open. Is there anyway to be sure that errors are being
written by syslog and not the nginx process itself?
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: [nginx-announce] nginx-1.9.15

[Kevin Worthington]

Hello Nginx users,

Now available: Nginx 1.9.15 for Windows
https://kevinworthington.com/nginxwin1915 (32-bit and 64-bit versions)

This version was built with OpenSSL 1.0.2g, so upgraded is strongly
encouraged.

These versions are to support legacy users who are already using Cygwin
based builds of Nginx. Officially supported native Windows binaries are at
nginx.org.

Announcements are also available here:
Twitter http://twitter.com/kworthington
Google+ https://plus.google.com/+KevinWorthington/

Thank you,
Kevin
--
Kevin Worthington
kworthington *@* (gmail]  [dot} {com)
http://kevinworthington.com/
http://twitter.com/kworthington
https://plus.google.com/+KevinWorthington/




On Tue, Apr 19, 2016 at 12:21 PM, Maxim Dounin  wrote:

> Changes with nginx 1.9.1519 Apr
> 2016
>
> *) Bugfix: "recv() failed" errors might occur when using HHVM as a
>FastCGI server.
>
> *) Bugfix: when using HTTP/2 and the "limit_req" or "auth_request"
>directives a timeout or a "client violated flow control" error might
>occur while reading client request body; the bug had appeared in
>1.9.14.
>
> *) Workaround: a response might not be shown by some browsers if HTTP/2
>was used and client request body was not fully read; the bug had
>appeared in 1.9.14.
>
> *) Bugfix: connections might hang when using the "aio threads"
>directive.
>Thanks to Mindaugas Rasiukevicius.
>
>
> --
> Maxim Dounin
> http://nginx.org/
>
> ___
> nginx-announce mailing list
> nginx-annou...@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-announce
>
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Making Tomcat accessible only through nginx reverse proxy

[gischethans]

I have a Tomcat server serving a web application and I have a Nginx server
running in front of it as a reverse proxy. Both the servers are on Intranet,
in the same domain network. The issue I am facing is, the tomcat server is
accessible through both IP addresses - if I use the Nginx IP, it redirects
to the Tomcat FQDN (expected) but if I ping using the FQDN
tomcat.domain.com, it reveals the real IP of the Tomcat server and not that
of Nginx server. Effectively, my Nginx server is not serving any purpose. I
was suggested to firewall the Tomcat instance, but based on my findings from
different forums, limiting Tomcat to listen to localhost seemed to be the
way to go. In order to prevent Tomcat from listening to other IPs, I added
"address=127.0.0.1" to the connector configuration. The entire connector
block is like this -

 
proxyPort="80"/> 

In the Nginx server, I have these lines for the server configuration.

server {
listen  80 default_server;
listen  [::]:80 default_server ipv6only=on;

server_name ;
location / {
proxy_pass ;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-for $proxy_add_x_forwarded_for;
}
}
Now, if I try to use the FQDN to access the web application, Chrome reports
ERR_CONNECTION_REFUSED. My Nginx configuration seems to be the culprit based
on what I understood. How can it be corrected?

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?2,266297,266297#msg-266297

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

Re: reuseport в конфигах nginx

[navern]

Пусть у нас хост на линуксе, старый nginx слушает порт 8080, новый 8081,
  действует правило перенаправления 80->8080, после старта второго nginx
  заменяем правило командочкой

  iptables -t nat -R PREROUTING 1 -p tcp --dport 80 -j REDIRECT --to-port 8081

  и ждём, когда все соединения со старым nginx'ом будут обработаны и
  закрыты, после чего старый nginx гасим.

  В других операционках пакетный фильтр управляется иначе, но схема та же


Хост на линуксе. На 80 порту слушает не только nginx. У nginx'а 
несколько IP адресов, не всегда известных. Конфигов с виртуалхостами 
около 10 тысяч. Получается нужно еще каждый раз во всех 10к конфигах 
менять порт, на котором слушаем? При этом избежать ситуации, когда в 
этот момент реалодится основной nginx(если предполагаем, что конфиги 
разделяемые).


Для трех виртуалхостов наверное норм решение.

Еще нужно потом будет управлять этими правилами.

У нас подобная схема работает для контейнеров с MySQL, там это удобно. 
Для nginx'а не очень подходит.


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

Re: Redirection problem again in new rules.

[Muhammad Yousuf Khan]

Thanks Alot Francis Daly, actually i was trying to understand the working
of rewrite and location rules how they handle the query. you explain it
very well. Thanks again for sharing such useful and detailed explanation. i
really appreciate that. :)



On Tue, Apr 19, 2016 at 4:23 AM, Francis Daly  wrote:

> On Mon, Apr 18, 2016 at 06:37:59PM +0500, Muhammad Yousuf Khan wrote:
>
> Hi there,
>
> > Thanks alot Francis Daly :). the try_file option worked for me and
> location
> > tip also worked but try_file seems more better approach.
>
> I'm glad you got it working for you.
>
> > Btw, can you please explain this paragraph. actually i am really sorry
> for
> > this newbie type question. actually i have been working as ssytem admin
> for
> > last 5 years. now my Firewall concepts of rules are collapsing with nginx
> > rules.
>
> No worries - nginx config follows its own rules, which are generally
> consistent but not necessarily the same as any other program.
>
> > >location /x { rewrite ^ /x.html redirect; }
> > >fails because "location /x" will match /x.html, so the second request
> > >will match the same location as the first one and the same redirect will
> > >happen again; and one way to avoid the loop is to make the "location"
> > >only match exactly "/x".
> > >Based on that, can you guess what the "~" in
> >
> > can you please explain how the second request creates the loop. if i use
> > break instead of redirect?
>
> I don't understand the question.
>
> What break, and what loop?
>
> I thought you had said that when you used "break" instead of "redirect"
> in the above "location /x", you got a 404. And that is what I would
> expect if the file $document_root/x.html does not exist. 404 is not a loop.
>
> Can you start with one specific configuration, and use the documentation
> (probably at http://nginx.org/r/rewrite, since that seems to be the
> troublesome one) to work out what will happen?
>
> Note: when a request arrives, the server-level "rewrite"-module directives
> (basically: if and rewrite) are used; if that does not complete the
> request, then the location is chosen, and the "rewrite"-modules directives
> in that location are used.
>
> If a "rewrite" leads to an external redirect, that completes the
> request; and the browser may then come back with a whole new request
> that is handled afresh.
>
> If the "rewrite" leads to an internal rewrite (to a new url), then the
> "subrequest" of the new url is handled according to the docs -- possibly
> with a whole new selection of the location to use, depending on the
> arguments given to the rewrite.
>
> So: show your (simplified, but complete) config; show your http request;
> show your http response; and if appropriate, describe the response that
> you wanted to get instead.
>
> "break" does exactly what it says in the documentation. If that is
> unclear, let's fix the documentation.
>
> f
> --
> Francis Dalyfran...@daoine.org
>
> ___
> 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: reuseport в конфигах nginx

[Evgeniy Berdnikov]

On Wed, Apr 20, 2016 at 12:12:21PM +0300, navern wrote:
> >  Да хоть на Юпитере. Он вообще-то в контейнере. Ядро может входящие
> >  коннекции перенаправлять на любой порт, и ip-адрес можно менять.
> >  Без разницы, как отличать новый сервер от старого, по ip или порту,
> >  но в любом случае их нужно как-то различать.
> Ок, предложите вариант решения данной задачи вашим способом?

 Пусть у нас хост на линуксе, старый nginx слушает порт 8080, новый 8081,
 действует правило перенаправления 80->8080, после старта второго nginx
 заменяем правило командочкой

 iptables -t nat -R PREROUTING 1 -p tcp --dport 80 -j REDIRECT --to-port 8081

 и ждём, когда все соединения со старым nginx'ом будут обработаны и
 закрыты, после чего старый nginx гасим.

 В других операционках пакетный фильтр управляется иначе, но схема та же.
-- 
 Eugene Berdnikov

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

Re: reuseport в конфигах nginx

[navern]

  Да хоть на Юпитере. Он вообще-то в контейнере. Ядро может входящие
  коннекции перенаправлять на любой порт, и ip-адрес можно менять.
  Без разницы, как отличать новый сервер от старого, по ip или порту,
  но в любом случае их нужно как-то различать.

Ок, предложите вариант решения данной задачи вашим способом?


  Не нужно поднимать два nginx'а на одинаковых портах. Вы пытаетесь
  известным Вам решением подменить задачу. Задача -- перенаправить
  соединения на новый сервер, а не просто иметь два параллельно
  работающих nginx'а.
Задача на самом деле не совсем такая. Но в целом я согласен, её можно 
решить и подобным способом.



Но reuseport не делает
  переброса соединений, как бы этого ни хотелось.
Ну так мне то и не нужен проброс соединений. Мне нужно, чтобы к моменту, 
когда я гасил старый контейнер, был новый запущенный. Потеря нескольких 
соединений в данном случае не очень критична.


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

Re: reuseport в конфигах nginx

[Evgeniy Berdnikov]

On Wed, Apr 20, 2016 at 11:37:50AM +0300, navern wrote:
> On 20.04.2016 11:19, Evgeniy Berdnikov wrote:
> >  Так же как и вашем. В чём проблема-то? Если в пересечении портов
> >  для bind(2), так порты нужно сделать разными, вот и всё.
> Nginx во фронтэнде. Какие разные порты?

 Да хоть на Юпитере. Он вообще-то в контейнере. Ядро может входящие
 коннекции перенаправлять на любой порт, и ip-адрес можно менять.
 Без разницы, как отличать новый сервер от старого, по ip или порту,
 но в любом случае их нужно как-то различать.

 Главное что сменить перенаправление syn'ов можно на ходу, не разрывая
 установленных ранее соединений.

> reuseport как раз позволяет при одинаковых портах поднять два
> контейнера с nginx'ом.

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

> >Поэтому зачем все эти патчи -- непонятно.
> Единственный смысл патча - слегка упростить конфигурацию. По факту,
> если бы была опция в основном конфиге что-то вроде enable_reuseport
> all; то ничего делать было бы не надо.

 С чего бы это? Вы прямо верите в какую-то магию: напиши в конфиге
 заклинание -- и заветное желание исполнится. Но reuseport не делает
 переброса соединений, как бы этого ни хотелось.
-- 
 Eugene Berdnikov

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

Re: reuseport в конфигах nginx

[navern]

On 20.04.2016 11:19, Evgeniy Berdnikov wrote:

  Так же как и вашем. В чём проблема-то? Если в пересечении портов
  для bind(2), так порты нужно сделать разными, вот и всё.

Nginx во фронтэнде. Какие разные порты?

reuseport как раз позволяет при одинаковых портах поднять два контейнера 
с nginx'ом.



Поэтому зачем все эти патчи -- непонятно.
Единственный смысл патча - слегка упростить конфигурацию. По факту, если 
бы была опция в основном конфиге что-то вроде enable_reuseport all; то 
ничего делать было бы не надо.


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

Re: reuseport в конфигах nginx

[Evgeniy Berdnikov]

On Wed, Apr 20, 2016 at 11:02:39AM +0300, navern wrote:
> On 20.04.2016 10:57, Evgeniy Berdnikov wrote:
> >  О какой альтернативе речь? Перенаправьте syn'ы на новый контейнер,
> >  и будет вам счастье без патчей и потерь входящих соединений.
> А как поднять два контейнера одновременно в вашем варианте?

 Так же как и вашем. В чём проблема-то? Если в пересечении портов
 для bind(2), так порты нужно сделать разными, вот и всё.

> И что делать с соединениями, которые висят по 10-15 минут?

 Ждать, очевидно. Разве есть другие варианты?

> Вопрос то вовсе не в syn пакетах, а в долгих соединениях.

 Вопрос этот reuseport'ом не решается: сколько ни жди завершения старых
 соединиений, в любой момент на старый сервер может прилететь новый запрос.
 А с перенаправлением syn'ов все новые соединения гарантированно идут
 на новый сервер. Поэтому зачем все эти патчи -- непонятно.
-- 
 Eugene Berdnikov

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

Re: reuseport в конфигах nginx

[navern]

On 20.04.2016 10:57, Evgeniy Berdnikov wrote:

  О какой альтернативе речь? Перенаправьте syn'ы на новый контейнер,
  и будет вам счастье без патчей и потерь входящих соединений.
А как поднять два контейнера одновременно в вашем варианте? И что делать 
с соединениями, которые висят по 10-15 минут? Вопрос то вовсе не в syn 
пакетах, а в долгих соединениях.


Альтернатива такая:
1) Опускаем один контейнер.
2) Поднимаем новый контейнер.

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

Re: reuseport в конфигах nginx

[Evgeniy Berdnikov]

On Tue, Apr 19, 2016 at 05:43:58PM +0300, navern wrote:
> >Вас не смущает, что при этом часть соединений будет потеряна?
> Ну это не супер приятно да, но альтернатива хуже.  Потому что в
> альтернативном варинте часть соединений будет невозможна на то
> время, пока мы опустили один контейнер, а потом подняли второй.

 О какой альтернативе речь? Перенаправьте syn'ы на новый контейнер,
 и будет вам счастье без патчей и потерь входящих соединений.
-- 
 Eugene Berdnikov

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

Re: (52) Empty reply from server

[Pankaj Chaudhary]

>>But your code snippet does not match exactly the types and return values
>>of that example. I don't know if that is something worth investigating.

I have tried to change match exactly the types and return values
of that example. but below is response curl: (52) Empty reply from server

>>Also, you may be able to make use of #3: "Blazing fast" instead.

but same response

>>And one final thing - I suspect that the request header "Cookie" will
>>be presented in the header_in structure under the name "cookie", not
>>the name "http_cookie". Possibly just making that change will cause your
>>code to find the value you want.

Tried to use the same now i am getting response only one word "cookie"
I have used below example to set custom header

ngx_int_tset_custom_header_in_headers_out(ngx_http_request_t *r,
ngx_str_t *key, ngx_str_t *value) {
ngx_table_elt_t   *h;

/*All we have to do is just to allocate the header...*/
h = ngx_list_push(>headers_out.headers);
if (h == NULL) {
return NGX_ERROR;
}

/*... setup the header key ...*/
h->key = *key;

/*... and the value.*/
h->value = *value;

/*Mark the header as not deleted.*/
h->hash = 1;

return NGX_OK;}

below is "curl -i" response

HTTP/1.1 200 OK
Server: nginx/1.9.12
Date: Wed, 20 Apr 2016 15:25:20 GMT
Content-Type: text/plain
Content-Length: 14
Connection: keep-alive
cookie: thisitestvalue
user_agent: 10.9 user
get-rese: Cookie


On Tue, Apr 19, 2016 at 11:12 PM, Francis Daly  wrote:

> On Tue, Apr 19, 2016 at 03:51:17PM +0530, Pankaj Chaudhary wrote:
>
> Hi there,
>
> > i am trying to search for one header with the specified name
> >
> > i am not able to get header value .
>
>
> https://www.nginx.com/resources/wiki/start/topics/examples/headers_management/
> lists four ways to try this. You are using something like #2: "Quick
> search".
>
> But your code snippet does not match exactly the types and return values
> of that example. I don't know if that is something worth investigating.
>
> Also, you may be able to make use of #3: "Blazing fast" instead.
>
> > ngx_str_tval = ngx_string("http_cookie");
>
> And one final thing - I suspect that the request header "Cookie" will
> be presented in the header_in structure under the name "cookie", not
> the name "http_cookie". Possibly just making that change will cause your
> code to find the value you want.
>
> Good luck with it,
>
> f
> --
> Francis Dalyfran...@daoine.org
>
> ___
> 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