We hit the same problem. First off, to work around this problem add the
following to your nginx configuration:
send_timeout 3600;
This will increase the time out to one hour which is long enough to
empty the buffer with a slow connection.
As to what's happening during these 60 seconds I can ans
Hello Davromaniak
Thanks for pointing me to this patch. I have made the needed changes and
was able to compile it just fine.
Iry
Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,243166,243169#msg-243169
___
nginx mailing list
nginx@nginx.org
_upload_module-2.2.0/ngx_http_upload_module.c:2877: error:
> ‘ngx_http_request_body_t’ has no member named ‘to_write’
> make[1]: *** [objs/addon/nginx_upload_module-2.2.0/ngx_http_upload_module.o]
> Error 1
> make[1]: Leaving directory `/root/nginx-1.4.1'
> make: *** [build]
]: *** [objs/addon/nginx_upload_module-2.2.0/ngx_http_upload_module.o]
Error 1
make[1]: Leaving directory `/root/nginx-1.4.1'
make: *** [build] Error 2
My configuration script is:
./configure --add-module=/var/tmp/ldap/nginx-auth-ldap-master
--add-module=../nginx_upload_module-2.2.0 --with-pcre=..
H
i
>
> After a 60 seconds timer was fired and client connection was
>
> closed as timed out.
>
> Yeah. That's what I feared. But the connection was definitely still
> open and data was being transferred.
You are still testing through your 2G GSM connection, right?
How can you be sure that this c
Hello!
On Tue, Aug 20, 2013 at 03:14:20PM +0200, Philip Hofstetter wrote:
> Hello!
>
> On Tue, Aug 20, 2013 at 1:26 PM, Maxim Dounin wrote:
>
> > 2013/08/20 09:34:31 [debug] 1692#0: *1101651 http upstream process non
> > buffered downstream
> > 2013/08/20 09:34:31 [info] 1692#0: *1101651 clie
Hello!
On Tue, Aug 20, 2013 at 1:26 PM, Maxim Dounin wrote:
> 2013/08/20 09:34:31 [debug] 1692#0: *1101651 http upstream process non
> buffered downstream
> 2013/08/20 09:34:31 [info] 1692#0: *1101651 client timed out (110: Connection
> timed out) while sending to client, client: 80.219.149.11
Hello!
On Tue, Aug 20, 2013 at 09:49:32AM +0200, Philip Hofstetter wrote:
> Ok. I have three debug logs now:
>
> http://www.gnegg.ch/debug-cancel.log
> is the first log I created where I quit curl once nginx has logged a
> 200 status with a truncated length to the access log (how can it log
> su
Ok. I have three debug logs now:
http://www.gnegg.ch/debug-cancel.log
is the first log I created where I quit curl once nginx has logged a
200 status with a truncated length to the access log (how can it log
success while it's still transmitting data?)
http://www.gnegg.ch/debug-full.log
is the sa
The last debug log I sent is not showing the full picture. In this
case, I was aborting the curl command once nginx has logged an
incomplete response (status=200 but too short length) to access.log,
but while it was still transferring data (how's that even possible)?
Hence the "connection reset by
Hi,
On Mon, Aug 19, 2013 at 7:05 PM, Lukas Tribus wrote:
> Looks like there is some timeout at 600 seconds (Time Spent: 0:09:58)? Any
> match
> in the haproxy or nginx configurations?
That's consistent with what nginx is logging to the error log. But it
doesn't make sense as there is data bei
Hi,
> % Total % Received % Xferd Average Speed Time Time Time
>Current
> Dload Upload Total Spent Left Speed
> 100 1196k 0 1196k 0 343 2047 0 --:--:-- 0:09:58 --:--:-- 1888
> curl: (56) Recv failure: Connection reset by p
Hello!
On Mon, Aug 19, 2013 at 02:07:09PM +0200, Philip Hofstetter wrote:
> Hi,
>
> I have a nginx (stock ubuntu config) as a reverse proxy in front of a
> haproxy in front of 5 more nginx machines which use fastcgi to talk to
> php-fpm.
>
> My issue is with the frontend proxy and long-running
Hi,
I have a nginx (stock ubuntu config) as a reverse proxy in front of a
haproxy in front of 5 more nginx machines which use fastcgi to talk to
php-fpm.
My issue is with the frontend proxy and long-running, very
slow requests.
The clients are very underpowered mobile barcode scanners u
Hello!
On Tue, May 28, 2013 at 04:52:14AM -0400, gadh wrote:
> i found the bug - the web server returned in "Content-Type" header just
> "text/html" and not added "charset=UTF-8".
> why text/html is not enough ?
For nginx, there should be no difference. But it looks like you
are debugging comp
i found the bug - the web server returned in "Content-Type" header just
"text/html" and not added "charset=UTF-8".
why text/html is not enough ?
Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,239608,239622#msg-239622
___
nginx mailing list
ng
when i use nginx 1.4.1 + 'gzip on', once in every 2 requests i get the
index.php (which its output is text/html) being downloaded by the browser as
unknown file type instead of displayed in it (the broswer displays the
"download & save" window and writes in this window
For closure: I took this to the bug tracker and a patch was posted that
resolves this issue:
http://trac.nginx.org/nginx/ticket/357
Apologies for newsletter spam.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,239327,239331#msg-239331
___
ng
.x86_64 #1 SMP Thu May 16 20:59:36 UTC
2013 x86_64 x86_64 x86_64 GNU/Linux
nginx compile flags:
CFLAGS="-g -O0" ./configure --with-pcre=/usr/local/src/nginx-1.4.1/pcre-8.32
--sbin-path=/usr/local/sbin --conf-path=/etc/nginx/nginx.conf
--pid-path=/var/run/nginx.pid --error-log-path=/var
Hello Nginx users,
Now available: Nginx 1.4.1 for Windows http://goo.gl/4kA8O (32-bit and
64-bit versions)
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
Changes with nginx 1.4.1 07 May 2013
*) Security: a stack-based buffer overflow might occur in a worker
process while handling a specially crafted request, potentially
resulting in arbitrary code execution (CVE-2013-2028); the bug had
21 matches
Mail list logo