Regarding URL Encode/Decode of the Parameter

[m.i]

Hello, I have a following problem with Nginx. Here is the scenario.

There is a client app that sends request to Nginx Proxy with following
parameter. The parameter is already url encoded.
GET /X/Y/Z.aspx?id=abc%3D%3D

Now, I noticed that Nginx applies url encode to % and make it as %25 when it
redirect the message. The parameter now become below.
GET /X/Y/Z.aspx?id=abc%253D%253D

I want Nginx to redirect the parameter as is. Below is the one that I want
Nginx to redirect.
GET /X/Y/Z.aspx?id=abc%3D%3D

Could you please, help me out to do what I want?

Any suggestions are very much welcome!

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

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

Re: nginx 1.13 binaries

[Paul Smith]

As Francis stated, you need to look for the mainline version, not the
stable version. They have different repositories.

http://nginx.org/packages/mainline/centos/6/x86_64/RPMS/


On Thu, Jul 27, 2017 at 12:47 PM, Gee Bunny  wrote:
> There might be talk of binaries being available on the page you linked, but
> if you check the repo link I provided (to the NGINX hosted YUM Repository
> for CentOS 6 x86_64) there's no version 1.13 it goes as high as nginx-1.12.1
> only.
>
> Don't take my word for it, see for yourself:
>
> http://nginx.org/packages/centos/6/x86_64/RPMS/
>
 My guess: they are already there.
>
 See http://nginx.org/en/linux_packages.html
>
>
>
> On Sat, Jul 22, 2017 at 9:45 PM, Gee Bunny  wrote:
>>
>> Are there plans to add nginx 1.13 to any of the yum repositories?
>>
>> Like:
>>
>> http://nginx.org/packages/centos/6/x86_64/RPMS/
>>
>> Some of us would like to run the latest version of NGINX with TLS1.3
>> support, without having to compile from source.
>>
>> Are there any plans or ETA to have nginx 1.13 aded to the repos within a
>> timely fashion? Or is the only option to get TLS1.3 support to compile from
>> source for the forseeable future?
>>
>> Thanks
>>
>> P.S. Awesome work on NGINX- best disruptive web-server tech to hit the
>> scene in 20+ years.
>
>
>
> ___
> 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: Problem with uWSGI and PATH_INFO

[Etienne Robillard]

Hi Roberto,

Le 2017-07-27 à 13:45, Roberto De Ioris a écrit :


by using something like this (in the config, tune the regexps as required):

[uwsgi]
route = ^/(.+?)/(.+)$ setscriptname:/$1
route = ^/(.+?)/(.+)$ setpathinfo:/$2

I use a dynamic regex URL resolver to resolve a request URI to a 
callback function. Also I prefer avoiding to modify uWSGI internal 
routing system for my basic use-case. I have no choice to fallback on 
using fastcgi until this is fixed either in nginx or uWSGI.


Etienne

--
Etienne Robillard
tkad...@yandex.com
http://www.isotopesoftware.ca/

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

[nginx] Cache: fixed max_size on win32.

[Ruslan Ermilov]

details:   http://hg.nginx.org/nginx/rev/72d3aefc2993
branches:  
changeset: 7075:72d3aefc2993
user:  Ruslan Ermilov 
date:  Wed Jul 26 13:13:51 2017 +0300
description:
Cache: fixed max_size on win32.

diffstat:

 src/http/ngx_http_file_cache.c |  1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diffs (11 lines):

diff -r 07a49cce21ca -r 72d3aefc2993 src/http/ngx_http_file_cache.c
--- a/src/http/ngx_http_file_cache.cTue Jul 25 17:21:59 2017 +0300
+++ b/src/http/ngx_http_file_cache.cWed Jul 26 13:13:51 2017 +0300
@@ -129,6 +129,7 @@ ngx_http_file_cache_init(ngx_shm_zone_t 
 if (shm_zone->shm.exists) {
 cache->sh = cache->shpool->data;
 cache->bsize = ngx_fs_bsize(cache->path->name.data);
+cache->max_size /= cache->bsize;
 
 return NGX_OK;
 }
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: nginx 1.13 binaries

[Gee Bunny]

There might be talk of binaries being available on the page you
linked, but if you check the repo link I provided (to the NGINX hosted
YUM Repository for CentOS 6 x86_64) there's no version 1.13 it goes as
high as nginx-1.12.1 only.

Don't take my word for it, see for yourself:

http://nginx.org/packages/centos/6/x86_64/RPMS/


>>> My guess: they are already there.

>>> See http://nginx.org/en/linux_packages.html



On Sat, Jul 22, 2017 at 9:45 PM, Gee Bunny  wrote:

> Are there plans to add nginx 1.13 to any of the yum repositories?
>
> Like:
>
> http://nginx.org/packages/centos/6/x86_64/RPMS/
>
> Some of us would like to run the latest version of NGINX with TLS1.3
> support, without having to compile from source.
>
> Are there any plans or ETA to have nginx 1.13 aded to the repos within a
> timely fashion? Or is the only option to get TLS1.3 support to compile from
> source for the forseeable future?
>
> Thanks
>
> P.S. Awesome work on NGINX- best disruptive web-server tech to hit the
> scene in 20+ years.
>
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: Problem with uWSGI and PATH_INFO

[Roberto De Ioris]

> Hi Roberto,
>
> That is not effective. My app uses PATH_INFO to resolve a URL (ie:
> /blog/create/) to a callback function.
>
> Could it be possible to just use :
>
> uwsgi_param PATH_INFO $path_info
>
> Assuming $path_info is the request_uri minus the location...
>
> E
>

Nope, as already said there is no way to manage this directly in nginx
(and technically any 'automatic' management could not be so easy to be
'fair'). You have to rewrite PATH_INFO and SCRIPT_NAME in uWSGI itself
following the links i pasted before.

To be more clear:

nginx passes to uWSGI:

PATH_INFO = /foo/bar

uWSGI receives it and rewrite it as

SCRIPT_NAME = /foo
PATH_INFO = /bar

by using something like this (in the config, tune the regexps as required):

[uwsgi]
route = ^/(.+?)/(.+)$ setscriptname:/$1
route = ^/(.+?)/(.+)$ setpathinfo:/$2

-- 
Roberto De Ioris
http://unbit.com
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: Problem with uWSGI and PATH_INFO

[Etienne Robillard]

Hi Roberto,

That is not effective. My app uses PATH_INFO to resolve a URL (ie: 
/blog/create/) to a callback function.


Could it be possible to just use :

uwsgi_param PATH_INFO $path_info

Assuming $path_info is the request_uri minus the location...

E

Le 2017-07-27 à 12:47, Roberto De Ioris a écrit :

Then just add

uwsgi_param SCRIPT_NAME "";

in uwsgi_params :)



--
Etienne Robillard
tkad...@yandex.com
http://www.isotopesoftware.ca/

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

Re: Problem with uWSGI and PATH_INFO

[Roberto De Ioris]

> Hi all,
>
> Le 2017-07-27 à 11:25, Francis Daly a écrit :
>> On Thu, Jul 27, 2017 at 07:45:28AM -0400, Etienne Robillard wrote:
>>
>> Hi there,
>>
>>> I'm not sure I understand the logic of this. Can someone please
>>> explain why the variable PATH_INFO is set to $document_uri in
>>> uwsgi_params?
>> My guess (without knowing the history):
>>
>> The uwsgi_params values are an example of what can be done. The
>> combination of SCRIPT_NAME and PATH_INFO in that file is consistent, and
>> is valid in some cases (that is, cases where the application corresponds
>> to the "root" of the server).
> Actually my problem is that SCRIPT_NAME is not defined in uwsgi_params.
> SCRIPT_NAME is a mandatory environment variable as per HTTP/1.1 spec.
>>
>> No-one has reported that there is a problem and provided a fix.
> That's a major issue. A standard WSGI application should be able to use
> a uWSGI upstream server within the "/" location block without the need
> to define any "mountpoints".
>

Then just add

uwsgi_param SCRIPT_NAME "";

in uwsgi_params :)


-- 
Roberto De Ioris
http://unbit.com
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: Problem with uWSGI and PATH_INFO

[Etienne Robillard]

Hi all,

Le 2017-07-27 à 11:25, Francis Daly a écrit :

On Thu, Jul 27, 2017 at 07:45:28AM -0400, Etienne Robillard wrote:

Hi there,


I'm not sure I understand the logic of this. Can someone please
explain why the variable PATH_INFO is set to $document_uri in
uwsgi_params?

My guess (without knowing the history):

The uwsgi_params values are an example of what can be done. The
combination of SCRIPT_NAME and PATH_INFO in that file is consistent, and
is valid in some cases (that is, cases where the application corresponds
to the "root" of the server).
Actually my problem is that SCRIPT_NAME is not defined in uwsgi_params. 
SCRIPT_NAME is a mandatory environment variable as per HTTP/1.1 spec.


No-one has reported that there is a problem and provided a fix.
That's a major issue. A standard WSGI application should be able to use 
a uWSGI upstream server within the "/" location block without the need 
to define any "mountpoints".



In general, only the administrator knows what SCRIPT_NAME and PATH_INFO
values are appropriate in any one case, so that's the person who should
configure the two to match their particular case.

Correct. Attempting to rewrite PATH_INFO as DOCUMENT_URI seems not a 
reliable solution for my simple use-case.



Perhaps it would be useful for something similar to exist for uwsgi? The
fact that it does not exist already suggests that no-one has enough of
a need, to arrange that it be added.

A $uwsgi_script_name variable would be a worthy addition.

I guess that a server-level "if" could "set" two variables that could be
used to populate SCRIPT_NAME and PATH_INFO, until a uwsgi_split_path_info
directive is introduced. And that might be enough to avoid the need for
a dedicated directive.

(Actually: perhaps fastcgi_split_path_info can be used directly, even
in a location{} which does not do fastcgi_pass? It should be easy enough
to test whether that can work.)


The hard part is usually deciding what exactly is wanted. After that,
the implementation can be considered.

Good luck with it,

f
Note that I don't use fastcgi_split_path_info. The only modification I 
did to fastcgi_params is:

fastcgi_param SCRIPT_NAME $fastcgi_script_name
fastcgi_param PATH_INFO $fastcgi_script_name

Etienne

--
Etienne Robillard
tkad...@yandex.com
http://www.isotopesoftware.ca/

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

Re: Problem with uWSGI and PATH_INFO

[Roberto De Ioris]

> Hi Roberto,
>
>
> Le 2017-07-27 à 09:52, Roberto De Ioris a écrit :
>>
>>> Hi again, this is not what manage-script-name is for. It is a
>>> uWSGI-specific option for when you only PATH_INFO and you want to
>>> generate
>>> SCRIPT_NAME accordingly. This requires to "mount" apps under specific
>>> paths.
> Ok. I really don't want to "mount" my app under a specific script name.
>>> uWSGI by itself does not rewrite the vars passed by the webserver, if
>>> you
>>> want to do it you have to use internal routing accordingly (or use a
>>> WSGI
>>> middleware that is generally more handy and portable, albeit annoying
>>> if
>>> you already have an entry point)
> Nginx internal routing seems a reasonable choice here. My app is looking
> like this:
>
> dispatch-django.uwsgi:
>
> def application(environ, start_response):
>wsgi_app = make_app()
>return wsgi_app(environ, start_response)
>
> Then I invoke uwsgi like so:
>

I was meaning uWSGI internal routing :)

http://uwsgi-docs.readthedocs.io/en/latest/InternalRouting.html

and yes, for manage-script-name to have effect you need to specify the
mountpoint of your app like described here:

http://uwsgi-docs.readthedocs.io/en/latest/Snippets.html#multiple-flask-apps-in-different-mountpoints

(it is flask app but it is the same concept)

-- 
Roberto De Ioris
http://unbit.com
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: Problem with uWSGI and PATH_INFO

[Etienne Robillard]

Hi Roberto,


Le 2017-07-27 à 09:52, Roberto De Ioris a écrit :



Hi again, this is not what manage-script-name is for. It is a
uWSGI-specific option for when you only PATH_INFO and you want to generate
SCRIPT_NAME accordingly. This requires to "mount" apps under specific
paths.

Ok. I really don't want to "mount" my app under a specific script name.

uWSGI by itself does not rewrite the vars passed by the webserver, if you
want to do it you have to use internal routing accordingly (or use a WSGI
middleware that is generally more handy and portable, albeit annoying if
you already have an entry point)
Nginx internal routing seems a reasonable choice here. My app is looking 
like this:


dispatch-django.uwsgi:

def application(environ, start_response):
  wsgi_app = make_app()
  return wsgi_app(environ, start_response)

Then I invoke uwsgi like so:
% uwsgi --socket localhost:8000 --wsgi-file dispatch-django.uwsgi 
--daemonize /var/log/uwsgi.log --enable-threads --workers 2
I think there's really something wrong with uWSGI internal routing 
system. The so-called "mountpoints" seems a little obscure to me. 
Perhaps the documentation should define a method to mount a dynamic 
django app without the need of --manage-script-name ?


Etienne

--
Etienne Robillard
tkad...@yandex.com
http://www.isotopesoftware.ca/

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

Re: Problem with uWSGI and PATH_INFO

[Roberto De Ioris]

> Hi Roberto,
>
> I use gevent-fastcgi for production. I wish to have the time to dive in
> the internals of uWSGI to understand how PATH_INFO and SCRIPT_NAME gets
> rewritten by uWSGI. I believe the implementation of --manage-script-name
> is incorrect and should be fixed to support having a empty or not set
> SCRIPT_NAME value.
>
> Etienne


Hi again, this is not what manage-script-name is for. It is a
uWSGI-specific option for when you only PATH_INFO and you want to generate
SCRIPT_NAME accordingly. This requires to "mount" apps under specific
paths.

uWSGI by itself does not rewrite the vars passed by the webserver, if you
want to do it you have to use internal routing accordingly (or use a WSGI
middleware that is generally more handy and portable, albeit annoying if
you already have an entry point)

-- 
Roberto De Ioris
http://unbit.com
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: Problem with uWSGI and PATH_INFO

[Etienne Robillard]

Hi Roberto,

I use gevent-fastcgi for production. I wish to have the time to dive in 
the internals of uWSGI to understand how PATH_INFO and SCRIPT_NAME gets 
rewritten by uWSGI. I believe the implementation of --manage-script-name 
is incorrect and should be fixed to support having a empty or not set 
SCRIPT_NAME value.


Etienne


Le 2017-07-27 à 09:01, Roberto De Ioris a écrit :

Hi,

if the url is something like /foo/bar and you have a location like

location /foo {
 ...
}

the WSGI standard expects SCRIPT_NAME to be /foo and PATH_INFO to be /bar

if you manually set SCRIPT_NAME to /foo in nginx, PATH_INFO will continue
to be /foo/bar.

Obviously having nginx managing it could be useful, but nowadays it is way
more versatile to manage this part in uWSGI itself (using the
manage-script-name or internal routing to manually rewrite apps), or
directly in your WSGI middleware.

your fastcgi adapter (i suppose flup) hardcodes this magic using the
classic apache fastcgi patterns (something we cannot rely on as we need to
support multiple environments)



--
Etienne Robillard
tkad...@yandex.com
http://www.isotopesoftware.ca/

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

Re: A Nginx Upstream DDoS Blackhole how does it work ?

[itpp2012]

See the 'upstream_EBLB_with_IWCP.txt' document and the pdf documentation,
the primary control (ie. signaling) should be (initiated) triggered by your
edge controllers or router.

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

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

Re: Problem with uWSGI and PATH_INFO

[Roberto De Ioris]

> Hi Roberto,
>
> My Django app runs perfectly ok under FastCGI and nginx but is not
> capable of resolving the proper PATH_INFO under uWSGI. In
> fastcgi_params, the value of PATH_INFO and SCRIPT_NAME are set to
> "$fastcgi_script_name". My nginx config looks like this:
>
> location / {
>
>   uwsgi_pass django;
>
> include uwsgi_params;
>
> }
>
> My wsgi app (django-hotsauce) really relay on a HTTP/1.1 compatible
> PATH_INFO value, just like in wsgiref. Why is it not possible to
> implement $uwsgi_script_name variable for nginx?
>
> Best regards,
> Etienne
>
>

Hi,

if the url is something like /foo/bar and you have a location like

location /foo {
...
}

the WSGI standard expects SCRIPT_NAME to be /foo and PATH_INFO to be /bar

if you manually set SCRIPT_NAME to /foo in nginx, PATH_INFO will continue
to be /foo/bar.

Obviously having nginx managing it could be useful, but nowadays it is way
more versatile to manage this part in uWSGI itself (using the
manage-script-name or internal routing to manually rewrite apps), or
directly in your WSGI middleware.

your fastcgi adapter (i suppose flup) hardcodes this magic using the
classic apache fastcgi patterns (something we cannot rely on as we need to
support multiple environments)

-- 
Roberto De Ioris
http://unbit.com
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: Problem with uWSGI and PATH_INFO

[Etienne Robillard]

Hi Roberto,

My Django app runs perfectly ok under FastCGI and nginx but is not 
capable of resolving the proper PATH_INFO under uWSGI. In 
fastcgi_params, the value of PATH_INFO and SCRIPT_NAME are set to 
"$fastcgi_script_name". My nginx config looks like this:


location / {

 uwsgi_pass django;

include uwsgi_params;

}

My wsgi app (django-hotsauce) really relay on a HTTP/1.1 compatible 
PATH_INFO value, just like in wsgiref. Why is it not possible to 
implement $uwsgi_script_name variable for nginx?


Best regards,
Etienne


Le 2017-07-27 à 08:36, Roberto De Ioris a écrit :



Hi, this is an example on how to configure multiple apps:

http://uwsgi-docs.readthedocs.io/en/latest/Snippets.html#multiple-flask-apps-in-different-mountpoints

Best thing to do is completely avoid nginx manipulating the SCRIPT_NAME
variable.


Even when under fastcgi, the WSGI standard expects a different meaning for
SCRIPT_NAME



--
Etienne Robillard
tkad...@yandex.com
http://www.isotopesoftware.ca/

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

Re: Secure Link Md5 Implementation

[anish10dec]

Thanks 

But what about the next part when actually we are in production and if there
is need for change of secret Key on Nginx.

" Is there a way to implement the token authentication with two secret key
i.e primary and secondary 
So that If the first one did not work, then try the second one. 
This would be helpful while changing the Secret Key in production so that
some user will be allowed with old secret and some with new secret whose
client has been updated."

Regards,
Anish

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

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

Problem with uWSGI and PATH_INFO

[Etienne Robillard]

Hi, uWSGI apparently does some weird voodoo tricks to manage SCRIPT_NAME 
and PATH_INFO when using nginx: "The WSGI standard dictates that 
|SCRIPT_NAME| is the variable used to select a specific application. 
Unfortunately u nginx is not able to rewrite PATH_INFO accordingly to 
SCRIPT_NAME. For such reason you need to instruct WSGI to map specific 
apps in the so called “mountpoint” and rewrite SCRIPT_NAME and PATH_INFO 
automatically"


I'm not sure I understand the logic of this. Can someone please explain 
why the variable PATH_INFO is set to $document_uri in uwsgi_params?


Thank you in advance,

E


--
Etienne Robillard
tkad...@yandex.com
http://www.isotopesoftware.ca/

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

Re: Transfer Zend App to new VPS show blank page

[Richard Stanway]

Your backend is returning a HTTP 500, which likely indicates a PHP Fatal
Error. You should check the error log for the site.

On Thu, Jul 27, 2017 at 10:28 AM, emios  wrote:

> I bought a new VPS and I try to transfer my working ZendApp (work in
> previous hosting with DirectAdmin). Now i install nginx with php5 and mysql
> i this is my php configuration - works well
>
> http://178.216.200.85/info.php
>
> I turn on display errors in php.ini and it shows me error in writable
> /_cache/ folder soo i set it to 777 permission. Error resolved but i still
> have error and don't see anything in my site
> http://178.216.200.85/index.php
>
> I don't have any .htaccess file
>
> Here is my /etc/nginx/sites-avaible/default content
>
> server {
> listen 80 default_server;
> listen [::]:80 default_server;
>
> # SSL configuration
> #
> # listen 443 ssl default_server;
> # listen [::]:443 ssl default_server;
> #
> # Self signed certs generated by the ssl-cert package
> # Don't use them in a production server!
> #
> # include snippets/snakeoil.conf;
>
> root /var/www/html;
>
> # Add index.php to the list if you are using PHP
> index index.php index.html index.htm index.nginx-debian.html;
>
> server_name 178.216.200.85;
>
> location / {
> # First attempt to serve request as file, then
> # as directory, then fall back to displaying a 404.
> try_files $uri $uri/ =404;
> }
>
>
> location ~ \.php$ {
> include snippets/fastcgi-php.conf;
> fastcgi_pass unix:/var/run/php5-fpm.sock;
> }
>
> location ~ /\.ht {
> deny all;
> }
> }
>
> What i should to add or someting to run my app in new server?
>
> Any advice will be very valuable
>
> Posted at Nginx Forum: https://forum.nginx.org/read.
> php?2,275676,275676#msg-275676
>
> ___
> 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: can variables be used in regular expressions?

[Maxim Dounin]

Hello!

On Thu, Jul 27, 2017 at 03:55:40AM -0400, foxgab wrote:

> i want to change the redirect location URI protocol to https if that is
> using, so i tried to configure like this:
> 
>   proxy_redirect  ~*^http://$host(/.*)?$ $scheme://$host$1;
> 
> but that didn't work, so i change it to:
> 
>   proxy_redirect  http://$http_host $scheme://$http_host;
> 
> then, it works. I suspect that the variable in regular expressions is treat
> as a string, hence my former directive failed, am I right?
> Is there any way to make variables effect in regular expressions?

No.  Regular expressions are compiled during configuration 
parsing, and using variables in them is not possible.

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

Re: Поддержка proxy-protocol в сторону бекендов

[Maxim Dounin]

Hello!

On Thu, Jul 27, 2017 at 10:11:08AM +0300, Максим Куприянов wrote:

> Подскажите, пожалуйста, есть ли сейчас в nginx поддержка PROXY-протокола
> для апстрим серверов (через proxy_pass, или в рамках upstream-секции). В
> документации нашел только про поддержку приема PROXY-соединений, но вот про
> бекенды ни слова.

Есть, но только в модуле stream.
http://nginx.org/en/docs/stream/ngx_stream_proxy_module.html#proxy_protocol

В рамках http-модуля он смысла не имеет, так как одно и то же 
соединение к бекенду может использоваться для запросов от разных 
клиентов.  Так что в случае http следует использовать 
соответствующие заголовки, такие как X-Real-IP или X-Forwarded-For:

proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

С этими заголовками умеет работать модуль realip в nginx 
(http://nginx.org/en/docs/http/ngx_http_realip_module.html) и 
различные модули в других http-серверах.

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

RE: [nginx] Fixed background requests with asynchronous operations.

[Eran Kornblau]

> -Original Message-
> From: nginx-devel [mailto:nginx-devel-boun...@nginx.org] On Behalf Of Maxim 
> Dounin
> Sent: Thursday, July 27, 2017 11:54 AM
> To: nginx-devel@nginx.org
> Subject: Re: [nginx] Fixed background requests with asynchronous operations.
> 
> The NGX_AGAIN returned from a content phase handler when you started an AIO 
> operation looks wrong: it means that nginx is already writing a response and 
> was blocked by a full socket buffer.  In this case nginx will assume it 
> should continue writing based on socket's write events, and will close the 
> connection as long as everything is written (no r->buffered, c->buffered is 
> set).  Before the Roman's patch the situation was the same: 
> there is not r->blocking check in ngx_http_writer(), so it would close the 
> connection as long as a write event happen for some reason.
> 
> Rather, you should use NGX_DONE and increment r->count if you want to wait 
> for an AIO operation result and continue processing yourself.
> 
> [...]

Thank you, Maxim, ran a quick test and returning NGX_DONE & r->main->count++ 
indeed solves the crash.
I'm quite sure that's what my code used to do few years ago, but then I changed 
it to return NGX_AGAIN, 
don't remember why...
Anyway, I will test it more thoroughly and update this thread if anything comes 
up.

Thanks,

Eran

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

Re: Secure Link Md5 Implementation

[c0nw0nk]

Like i said before

c0nw0nk Wrote:
---
> Update your web application for example (PHP) first then how ever many
> hours later when all caches for your web application have cleared
> restart your Nginx so it only accepts secure links.


Update your app first so your app outputs secured links.

Then when all caches and users are ready update Nginx config / restart Nginx
to force secured links only.

Both of your links

http://testapp.com/video/master.m3u8?token=xyz=123

http://testapp.com/video/master.m3u8 

Will work without Nginx being updated thats why you update your app outputs
first common sense that way everyone gets using the secured link without it
being secured but your logs will show you accepting ?token 

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

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

Re: Filter installation for WebSocket protocol in Nginx.

[Maxim Dounin]

Hello!

On Sat, Jul 22, 2017 at 11:10:02AM -0400, mohini wrote:

> I have an working nginx module (http_content_Modify_module) that acts as a
> proxy and manipulates some specific http data coming to the proxy before
> sending it to the upstream server.Used nginx1.6.2 for this and was
> implemented by installing filters in the "post-configuration" setup.
> Now I need to move from http to websocket protocol support. 
> By changing the configuration file to support "Upgrade" header,
> http_content_Modify_module  was able to talk to upstream webSocket server. 
> However I am not sure if nginx supports filter installation for websockets
> like it does for http so that I can manipulate/change data coming over the
> websocket
> before sending it to upstream.

No, it is not supported.

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

Re: [nginx] Fixed background requests with asynchronous operations.

[Maxim Dounin]

Hello!

On Mon, Jul 24, 2017 at 10:08:20AM +, Eran Kornblau wrote:

> Hi Roman,
> 
> I got a GitHub issue opened few days ago, that my module doesn't work 
> following this commit -
> https://github.com/kaltura/nginx-vod-module/issues/645#issuecomment-317027706
> 
> The situation is as follows -
> 1. My module's content phase handler runs and performs an async read request -
>   a. It calls ngx_file_aio_read which returns NGX_AGAIN
>   b. Increments r->blocked
>   c. Sets r->aio to 1
>   (code here - 
> https://github.com/kaltura/nginx-vod-module/blob/master/ngx_file_reader.c#L392)
> 2. The NGX_AGAIN status propagates up to ngx_http_core_content_phase which 
> calls ngx_http_finalize_request
>   with this status.
> 3. r->buffered, c->buffered, and r->postponed are all false, so this if:
>   
> https://github.com/nginx/nginx/blob/master/src/http/ngx_http_request.c#L2456
>   is skipped (it used to enter before the patch since r->blocked is 1)
>   In addition, r == c->data, so at the end, ngx_http_finalize_request 
> calls ngx_http_finalize_connection
> 4. Since r->main->count == 1 and r->keepalive == 1, this function calls 
> ngx_http_set_keepalive
> 5. ngx_http_set_keepalive calls ngx_http_free_request which destroys the pool 
> even though it has aio pending.
> 
> Please let me know if you think I'm doing something wrong here (I can, for 
> example, increment r->main->count,
> but this is not done in any of the other places that do blocked++)

The NGX_AGAIN returned from a content phase handler when you 
started an AIO operation looks wrong: it means that nginx is 
already writing a response and was blocked by a full socket 
buffer.  In this case nginx will assume it should continue writing 
based on socket's write events, and will close the connection as 
long as everything is written (no r->buffered, c->buffered is 
set).  Before the Roman's patch the situation was the same: 
there is not r->blocking check in ngx_http_writer(), so it would 
close the connection as long as a write event happen for some 
reason.

Rather, you should use NGX_DONE and increment r->count if you want 
to wait for an AIO operation result and continue processing 
yourself.

[...]

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

Transfer Zend App to new VPS show blank page

[emios]

I bought a new VPS and I try to transfer my working ZendApp (work in
previous hosting with DirectAdmin). Now i install nginx with php5 and mysql
i this is my php configuration - works well

http://178.216.200.85/info.php

I turn on display errors in php.ini and it shows me error in writable
/_cache/ folder soo i set it to 777 permission. Error resolved but i still
have error and don't see anything in my site
http://178.216.200.85/index.php

I don't have any .htaccess file

Here is my /etc/nginx/sites-avaible/default content

server {
listen 80 default_server;
listen [::]:80 default_server;

# SSL configuration
#
# listen 443 ssl default_server;
# listen [::]:443 ssl default_server;
#
# Self signed certs generated by the ssl-cert package
# Don't use them in a production server!
#
# include snippets/snakeoil.conf;

root /var/www/html;

# Add index.php to the list if you are using PHP
index index.php index.html index.htm index.nginx-debian.html;

server_name 178.216.200.85;

location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
}


location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/var/run/php5-fpm.sock;
}

location ~ /\.ht {
deny all;
}
}

What i should to add or someting to run my app in new server?

Any advice will be very valuable

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

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

can variables be used in regular expressions?

[foxgab]

i want to change the redirect location URI protocol to https if that is
using, so i tried to configure like this:

  proxy_redirect  ~*^http://$host(/.*)?$ $scheme://$host$1;

but that didn't work, so i change it to:

  proxy_redirect  http://$http_host $scheme://$http_host;

then, it works. I suspect that the variable in regular expressions is treat
as a string, hence my former directive failed, am I right?
Is there any way to make variables effect in regular expressions?

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

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

Поддержка proxy-protocol в сторону бекендов

[Максим Куприянов]

Привет!

Подскажите, пожалуйста, есть ли сейчас в nginx поддержка PROXY-протокола
для апстрим серверов (через proxy_pass, или в рамках upstream-секции). В
документации нашел только про поддержку приема PROXY-соединений, но вот про
бекенды ни слова.

--
С уважением,
Максим Куприянов
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru