I did some performance tests and it seemed to me as-if the status stub
caused a bit of a performance hit but nothing really concerning. However
for the status stub doesn't really give a lot of useful information IMO
because its just supposed to be a placeholder for an nginx+ status page-
I'm going
j.o.l:
Any other idea what to try or check?
I would write two separate server blocks,
server {
listen 8080;
server_name xxx;
root /usr/local/nginx/conf/websites/xxx;
autoindex on;
types {
application/x-ms-application application;
}
}
server {
listen 443 ssl;
ssl_cer
after some more experiments it looks like I was caught by a looking at
cached data. I was reloading the file for https as it was displayed as text
(happens to be readable xml). However this reload was answered with
not-modified without content-type (which is afaik standard conformant).
Only on har
yes, nginx -t reports OK.
I tried the empty types block with default_type as suggested - no change to
the behavior.
I verified that there is no other block processing the request. There is no
other block that uses that certificate on port 443, and the port 8080 is
used for that server block only.
Hello!
On Wed, Mar 09, 2016 at 10:56:40AM -0500, vizl wrote:
> Thank you.
> We don't make any changes with files or overwrite them while sendfile
> processing it.
> Only create temp file and then mv it.
The debug log suggests this is not true.
> Maybe Is it the same bug concerned with treads
Are you sure this configuration gets loaded (nginx -t OK, no error on
configuration -re-loading)?
You could try to replace your types block with an empty one (to override
defaults if they are defined at upper level, or simply remove them) and add
the following directive:
default_type application/x
Thank you.
We don't make any changes with files or overwrite them while sendfile
processing it.
Only create temp file and then mv it.
Maybe Is it the same bug concerned with treads aio like in this messeges,
https://forum.nginx.org/read.php?21,264701,265016#msg-265016
and it would be fixed in f
Hello!
On Wed, Mar 09, 2016 at 09:28:20AM -0500, vizl wrote:
> Debug log regarding to hanged PID 7479 http://dev.vizl.org/debug.log.txt
This looks like a threads + sendfile() loop due to non-atomic updates of
underlying file, similar to one recently reported on the Russian
mailing list.
Corr
On 03/09/2016 01:24 PM, Francis Daly wrote:
> On Wed, Mar 09, 2016 at 11:31:08AM +, Peter Molnar wrote:
>
> Hi there,
>
>> I'm facing some strange, unexpected regex behaviour in my setup.
>
> I think the answer is at http://nginx.org/r/rewrite and the "last" flag.
You were right about this
Debug log regarding to hanged PID 7479 http://dev.vizl.org/debug.log.txt
Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,264764,265188#msg-265188
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
If your backend is sensitive to keepalive traffic (mine are), then my
advice is to enable keepalives as far into your stack as you can.
i.e. I have nginx fronting haproxy and varnish, I enable keepalives to both
haproxy and varnish add have them add a "connection: close" header to their
backend re
On Wed, Mar 09, 2016 at 11:31:08AM +, Peter Molnar wrote:
Hi there,
> I'm facing some strange, unexpected regex behaviour in my setup.
I think the answer is at http://nginx.org/r/rewrite and the "last" flag.
What do you want to happen if the incoming request is for
/wp-content/cache/file-18
Dear nginx.org,
I'm facing some strange, unexpected regex behaviour in my setup.
Nginx is 1.9.12, self compiled, with openssl-1.0.2g and with the
following modules:
- echo-nginx-module (https://github.com/agentzh/echo-nginx-module.git)
- headers-more-nginx-module
(https://github.com/agentzh/header
13 matches
Mail list logo
