Custom Query (2297 matches)

http {

real_ip_header X-Real-IP; set_real_ip_from 127.0.0.1;

server {

listen 8000; real_ip_header X-Forwarded-For;

location / {

....

}

}

}

local test: #curl ​http://127.0.0.1:8000/ $remote_addr = "127.0.0.1"

#curl ​http://127.0.0.1:8000/ -H "X-Real-IP: 1.1.1.1" $remote_addr = "1.1.1.1"

#curl ​http://127.0.0.1:8000/ -H "X-Forwarder-For: 2.2.2.2" $remote_addr = "2.2.2.2"

#curl ​http://127.0.0.1:8000/ -H "X-Forwarder-For: 2.2.2.2" -H "X-Real-IP: 1.1.1.1" $remote_addr = "2.2.2.2"

why not location level tack effect? why X-real-IP tack effect?

Hello

I want to report your channel #nginx on Freenode IRC server, I saw you have listed that channel as official helping channel for Nginx. I will be short I just want to say something honestly.

I have experience with a lot of "helping" channels there, I cannot say all but most of them have officials who have big personal issues.

I will say what happened. I am using Nginx for some time now, I needed to make complex rewrite directive. I have read 2 Nginx books and read Rewrite module manual but couldn't make the rewrite liek it should be. So I honestly asked for help on channel #nginx on Freenode IRC server. One guy insulted me in very harsh way so I told him I will not beg for help at all costs and to stop insulting me, then shrotly after that a lot people in the channel jumped on me like dogs :) (yeah I told you personal problems.. ) they said "he is regular here and who are you..? etc." so I ignored one by one and waited for mute or ban on the channel (as my experience is like this with almost all channels on Freenode IRC server - they abuse power to insult if you counter them they will ban you) so after 10 or more hours of asking the same question again if someone can help me, I got replies from 6-7 people who didn't even saw what I am asking I guess, they posted some links from which 2 were total trash, and one was link that was of no help. I am well aware that they don't know how to do what I was asking or they don't care. When I said that the links were of no use I got muted on the channel.. I am not sure how they are related to Nginx but I saw you listed their IRC channel on your website so I wanted you to know with who you are dealing here..

That is all.

Relevant settings

To ensure that chunked encoding is passed directly to the upstream server rather than being buffered until the request is complete.

proxy_http_version 1.1; proxy_request_buffering off;

Description

I have a client that one of my developers has been working on that is getting dropped connections during large post operations if the upstream application raises an error at all.

The application may produce a 409 conflict error at the beginning of a large file upload POST message from this client (OSX written using CFNetwork framework) and this causes the nginx server to enter the linger state to consume the remainder of the POST message. Unfortunately if proxying the client from an SSL connection nginx gets a 0 bytes SSL_read and returns an SSL_get_error of 5 (SSL_ERROR_SYSCALL error). This causes nginx to believe that the client has closed the connection (which it hasn't) so it cleans up and drops the connection.

The ability to ensure that we aren't pooling up files being uploaded is important for this application so we need to pass the request like this without buffering it.

Additional points

If using plain HTTP nginx drains the lingering request properly after sending the error response to the client and the client does not get connected. The client then responds with the received error response rather than the disconnect message that one gets out of the CFNetwork framework if the request doesn't complete.

It has been verified that nginx has dropped the connection by using the client software in the working HTTP mode and routing the request through STUNNEL to the nginx server which also shows that the nginx server is dropping the connection and not the client and results in the same failure.

This is not observable at all until the post size reaches a good size, presumably filling any buffer/queue at the server prior to the switch to linger handling.

Using a weak cipher (RC4-MD5) as the only setting I was able to analyse the traffic and confirm that following the proxy sending back the 409 to the client, the client continued to try to send chunks of data but was disconnected by the nginx proxy.

I also tried adding an ERR_peek_last_error() to ngx_ssl_handle_recv if it detected SSL_ERROR_SYSCALL but this matched what was coming back as errno (0) and didn't provide any additional indication of the cause of the failure.

On some occasions the linger works as expected however in most cases the connection is terminated prior to the client finishing sending.

All testing has been done locally and I have experiemented with extending the linger values as a matter of course even though I can see that this isn't the problem.

Test Configuration

user www www; worker_processes 5;

events {

worker_connections 4096;

debug_connection 192.168.178.1;

}

http {

include /usr/local/etc/nginx/mime.types; default_type application/octet-stream;

proxy_buffering off; large_client_header_buffers 4 12k; proxy_http_version 1.1;

server {

listen 192.168.178.124:443 ssl; ssl_certificate /mytest/server.crt; ssl_certificate_key /mytest/server.key; access_log /mytest/custom.log; error_log /mytest/error.log warn; underscores_in_headers on;

location /api {

client_max_body_size 0; keepalive_timeout 0; proxy_request_buffering off; proxy_set_header BasePath "/api"; proxy_set_header HOST $http_host; proxy_set_header X-Forwarded-Proto $scheme; proxy_read_timeout 1800; proxy_send_timeout 1800; proxy_pass ​http://127.0.0.1:8081;

}

}

}

Debug events from the disconnect.

2016/07/15 13:44:41 [debug] 13841#100298: *9 SSL_read: 4096 2016/07/15 13:44:41 [debug] 13841#100298: *9 lingering read: 4096 2016/07/15 13:44:41 [debug] 13841#100298: *9 SSL_read: 4096 2016/07/15 13:44:41 [debug] 13841#100298: *9 lingering read: 4096 2016/07/15 13:44:41 [debug] 13841#100298: *9 SSL_read: 4096 2016/07/15 13:44:41 [debug] 13841#100298: *9 lingering read: 4096 2016/07/15 13:44:41 [debug] 13841#100298: *9 SSL_read: 0 2016/07/15 13:44:41 [debug] 13841#100298: *9 SSL_get_error: 5 2016/07/15 13:44:41 [debug] 13841#100298: *9 peer shutdown SSL cleanly 2016/07/15 13:44:41 [debug] 13841#100298: *9 lingering read: 0 2016/07/15 13:44:41 [debug] 13841#100298: *9 http request count:1 blk:0 2016/07/15 13:44:41 [debug] 13841#100298: *9 http close request 2016/07/15 13:44:41 [debug] 13841#100298: *9 http log handler 2016/07/15 13:44:41 [debug] 13841#100298: *9 free: 00000008026DF000 2016/07/15 13:44:41 [debug] 13841#100298: *9 free: 000000080250D000 2016/07/15 13:44:41 [debug] 13841#100298: *9 free: 0000000802482000, unused: 1 2016/07/15 13:44:41 [debug] 13841#100298: *9 free: 000000080250C000, unused: 0 2016/07/15 13:44:41 [debug] 13841#100298: *9 free: 00000008026E0000, unused: 2949 2016/07/15 13:44:41 [debug] 13841#100298: *9 close http connection: 17 2016/07/15 13:44:41 [debug] 13841#100298: *9 SSL_shutdown: 1 2016/07/15 13:44:41 [debug] 13841#100298: *9 event timer del: 17: 1468590286811 2016/07/15 13:44:41 [debug] 13841#100298: *9 reusable connection: 0 2016/07/15 13:44:41 [debug] 13841#100298: *9 free: 0000000802487000 2016/07/15 13:44:41 [debug] 13841#100298: *9 free: 0000000802406800 2016/07/15 13:44:41 [debug] 13841#100298: *9 free: 00000008024E0800, unused: 24 2016/07/15 13:44:41 [debug] 13841#100298: *9 free: 00000008024E0E00, unused: 400