Hi Max,
thanks for the explanation, I agree that from the traces, it really
looks like there were no data available in the socket from the upstream,
thus a different situation than I posted the first time. I will try to
reproduce the problem with both, debug log and wireshark traces that
will matc
Hello!
On Fri, Oct 17, 2014 at 12:48:43AM +0200, Jiri Horky wrote:
[...]
> 2014/10/17 00:41:55 [debug] 27396#0: *12485 connect to 1.1.1.1:,
> fd:184 #12552
Here connection is stablished to an upstream server.
> 2014/10/17 00:41:55 [debug] 27396#0: *12485 http upstream connect: -2
> 2014/10
Hey Itpp2012 thanks for another fantastic build <3! :D
I have a bit of a question to do with PHP running with your builds.
So i run a site in the top 20,000 sites on windows ofcourse using your
builds and today i had a big influx in traffic not a DDoS but more than PHP
could handle it seems.
So
Something else must be going on here. Looking at your ssl_cipher
string, you're opening with a rough declaration of specific ciphers you'll
support, none of which should pull in RC4. It's specific enough in fact
that your subsequent excluded ciphers don't even come into play. To test
this I sw
Hi again,
I just realized that the debug log I posted previously was with a
different setting (thus the SSL and keepalive there):
location / {
proxy_pass https://my-upstream;
proxy_read_timeout 90;
}
upstream my-upstream {
ip_hash ;
server 1.1.1.1:;
Hi Maxim,
here is the debug log of one failed connection:
2014/10/17 00:18:30 [debug] 25783#0: *8190 http keepalive handler
2014/10/17 00:18:30 [debug] 25783#0: *8190 malloc: 00BE44F0:1024
2014/10/17 00:18:30 [debug] 25783#0: *8190 SSL_read: 1024
2014/10/17 00:18:30 [debug] 25783#0: *8190
I can do this, but I guess my whole question was does this mean exclusion
bits are broken?
I'm personally partial to just outright declaring my supported ciphers
rather than using the exclusion bits. My personal server is aggressively
strict, the setup for our production gear is much less so.
what does cipherscan says?
https://github.com/jvehent/cipherscan
you can run that from the server nginx runs on
Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,254028,254082#msg-254082
___
nginx mailing list
nginx@nginx.org
http://mailman.ng
I'm personally partial to just outright declaring my supported ciphers
rather than using the exclusion bits. My personal server is aggressively
strict, the setup for our production gear is much less so. Either way it
allows me to know exactly what's available to clients.
For lunatics with DSA
Hello!
On Thu, Oct 16, 2014 at 09:35:14PM +0200, Jiri Horky wrote:
> Hi,
>
> thanks for the quick response. I tried it with nginx/1.7.6 but
> unfortunately, the errors still show up. However, I did not try to
> confirm that these were with the same trace, but I strongly suspect so.
> I will conf
I'm sure. I'm very, very sure the correct site is being tested.
On Thu, Oct 16, 2014 at 4:23 PM, mex wrote:
> hi,
>
> > >
> > > - make sure you are testing correct server.
> > >
>
>
> i'd suggest to configure an additional access/error-log
> in that server {} - block, to be 100% sure.
>
>
> re
hi,
> >
> > - make sure you are testing correct server.
> >
i'd suggest to configure an additional access/error-log
in that server {} - block, to be 100% sure.
regards,
mex
Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,254028,254077#msg-254077
_
Hi,
thanks for the quick response. I tried it with nginx/1.7.6 but
unfortunately, the errors still show up. However, I did not try to
confirm that these were with the same trace, but I strongly suspect so.
I will confirm that hopefully tomorrow. Anything other I should try?
Regards
Jiri Horky
On
On 16/10/2014 22:22 +0400, Maxim Dounin wrote:
> If a location with "internal" keyword is selected for an external
> request, the 404 error is generated. The error is handled as
> usual, and it's subject to error_page processing if one is
> configured.
>
> The documentation is here:
>
> http:/
Hello!
On Thu, Oct 16, 2014 at 08:26:55PM +0400, Filipp Gunbin wrote:
> Hi, today I've noticed a strange thing regarding "internal" and
> "error_page" directives.
>
> I have a config similar to this:
>
> location ~ {
> internal;
> proxy_pass ;
> error_page 404 = /other_location$uri;
> }
Hi,
Everything is loading OK and nginx -t (or service nginx configtest) show
the config is ok and I am testing the correct server.
Another poster suggested upgrading openssl to 1.0.1j but I'd have to build
from source to do that and I'm not sure what affect it would have against
nginx
On Thu
On Oct 16, 2014, at 8:25 PM, Bráulio Bhavamitra wrote:
> Valentin, do you know if "access_log off;" started to work on a
> location block on specific version of nginx? I've tried with the
> version from ubuntu trusty (1.4.7) and it didn't work.
I believe it was there in 0.0.10.
http://hg.nginx.
Thanks Valentin! I didn't realize fancyindex could be the culprit. I'll
follow up with the fancyindex developer.
On Thu, Oct 16, 2014 at 5:58 AM, Valentin V. Bartenev
wrote:
> On Wednesday 15 October 2014 19:24:11 Greg Barker wrote:
> > Thanks Valentin. Here's my config:
> > https://gist.github.
Hi, today I've noticed a strange thing regarding "internal" and
"error_page" directives.
I have a config similar to this:
location ~ {
internal;
proxy_pass ;
error_page 404 = /other_location$uri;
}
What I'm surprised about is that if an external request comes to this
location, we go the /
Valentin, do you know if "access_log off;" started to work on a
location block on specific version of nginx? I've tried with the
version from ubuntu trusty (1.4.7) and it didn't work.
On Fri, Oct 3, 2014 at 8:22 AM, Valentin V. Bartenev wrote:
> On Friday 03 October 2014 08:17:22 Bráulio Bhavamit
On Thu, Oct 16, 2014 at 2:58 PM, Maxim Dounin wrote:
> Hello!
>
> On Thu, Oct 16, 2014 at 02:41:33PM +0100, Miguel Clara wrote:
>
> > Hum... makes sense when sni is involved yes, but I get the same issue if
> > using the same certificate (wildcard) for 2 subdomains our my dev
> > environment.
> >
Hello!
On Thu, Oct 16, 2014 at 02:41:33PM +0100, Miguel Clara wrote:
> Hum... makes sense when sni is involved yes, but I get the same issue if
> using the same certificate (wildcard) for 2 subdomains our my dev
> environment.
>
> say "blog.domain.com" and "forums.domain.com" and I tested with
>
Hum... makes sense when sni is involved yes, but I get the same issue if
using the same certificate (wildcard) for 2 subdomains our my dev
environment.
say "blog.domain.com" and "forums.domain.com" and I tested with
cert/key_path define in the server's blocks and in conf.d/ssl.conf (which
is read
Hello!
On Thu, Oct 16, 2014 at 10:17:15AM +0200, Jiri Horky wrote:
> Hi list,
>
> we are seeing sporadic nginx errors "upstream prematurely closed
> connection while reading response header from upstream" with nginx/1.6.2
> which seems to be some kind of race condition.
> For debugging purposes
On Thu, Oct 16, 2014 at 08:42:26AM -0400, igorb wrote:
Hi there,
> Thanks again for detailed explanation. Now I almost grasped how try_files
> works. "Almost" because I still do not see why the following does not work:
There is a defect which is involved here, and probably interferes:
http://tr
Hello!
On Thu, Oct 16, 2014 at 03:40:44AM -0400, Jessica Litwin wrote:
> Hello
>
> I seem to have a bit of a problem. In my vhost's server {}; block, I have:
>
> ssl_ciphers
> EECDH+aRSA+AESGCM:EECDH+aRSA+AES:EDH+aRSA+AESGCM:EDH+aRSA+AES:DES-CBC3-SHA:!EXP:!CAMELLIA:!DSS:!MEDIUM:!LOW:!aNULL:
Hello!
On Thu, Oct 16, 2014 at 12:37:19AM +0100, Miguel Clara wrote:
> listen 443 ssl spdy;
>
> Actually but sni is working fine sslabs reports the correct certs... just
> tells me SSLv3 is on in all when its only set for one of the domains...
> At first I had " ssl_protocols TLSv1 TLSv1
It seems that the need for sslv3 was not so important, and so I've disabled
it completely, this was on a production machine so I can't really be
playing much with it :)
However I'll try to reproduce this in our dev box see what we get, and post
the results/config in a min.
Melhores Cumprimentos
On Wednesday 15 October 2014 19:24:11 Greg Barker wrote:
> Thanks Valentin. Here's my config:
> https://gist.github.com/fletchowns/13680a9d101f96d5f728
>
> $ /opt/nginx-1.6.2/sbin/nginx -V
> nginx version: nginx/1.6.2
> built by gcc 4.7.2 (Debian 4.7.2-5)
> TLS SNI support enabled
> configure argu
Thanks again for detailed explanation. Now I almost grasped how try_files
works. "Almost" because I still do not see why the following does not work:
server {
listen 8080 default_server;
root /usr/share/nginx/html;
autoindex on;
location /x/ {
alias /test/;
location ~ ^/x/(test.*) {
try_files $1
On Thu, Oct 16, 2014 at 9:03 PM, igorb wrote:
> That does not work either. What works is try_files "" =404 together with an
> explicit alias as Francis Daly described in another post.
>
did you put it inside the aliased location block? That'd explain why
it doesn't work (as francis said, $documen
On Thu, Oct 16, 2014 at 07:55:48AM -0400, igorb wrote:
Hi there,
> Thanks, try_files "" =404 works indeed as long as the regexp location block
> contains the necessary alias.
That sounds correct.
"alias" sets $document_root. try_files concatenates $document_root with
its "file" argument. (It do
That does not work either. What works is try_files "" =404 together with an
explicit alias as Francis Daly described in another post.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,254033,254043#msg-254043
___
nginx mailing list
nginx@nginx.o
Thanks, try_files "" =404 works indeed as long as the regexp location block
contains the necessary alias. I.e. the original example modified like in:
server {
listen 8080 default_server;
root /usr/share/nginx/html;
autoindex on;
location /x/ {
alias /test/;
location ~ ^/x/test {
On Thu, Oct 16, 2014 at 8:25 PM, igorb wrote:
> I tried that, but it still does not work. The following config as before
> still gives 404 for localhost/x/test.html :
>
> server {
> listen 8080 default_server;
> root /usr/share/nginx/html;
> autoindex on;
>
> locati
On Thu, Oct 16, 2014 at 07:40:17AM +0200, Sandra Snan wrote:
> On Thu, 16 Oct 2014 00:02:11 +0100, Francis Daly wrote:
Hi there,
> > Can you show the output of "grep SCRIPT /etc/nginx/fastcgi_params"
> > on the servers? (One output is fine, if the two are identical.)
>
> This was the problem; t
On Thu, Oct 16, 2014 at 07:09:44AM -0400, igorb wrote:
Hi there,
> location ~ ^/x/(test.*)$ {
> alias /test/$1;
> try_files $uri =404;
> }
> However that still gives 404 for localhost/x/test.html . Does that mean that
> try_files cannot be used at
I tried that, but it still does not work. The following config as before
still gives 404 for localhost/x/test.html :
server {
listen 8080 default_server;
root /usr/share/nginx/html;
autoindex on;
location /x/ {
alias /test/;
}
locat
On Thu, Oct 16, 2014 at 8:09 PM, igorb wrote:
> I tried to add explicit alias to the regexp location:
>
> server {
> listen 8080 default_server;
> root /usr/share/nginx/html;
> autoindex on;
>
> location /x/ {
> alias /test/;
> }
>
>
I tried to add explicit alias to the regexp location:
server {
listen 8080 default_server;
root /usr/share/nginx/html;
autoindex on;
location /x/ {
alias /test/;
}
location ~ ^/x/(test.*)$ {
alias /test/$1;
On Oct 16, 2014, at 1:38 PM, igorb wrote:
> [...]
> So what is wrong with the usage of try_files in the initial regexp-based
> location config?
That is because a location defined with a regular expression has no fixed
length to make a replacement in try_files, which is what alias do.
--
Sergey
I could not figure out why try_files in a nested location defined with a
regexp does not work in nginx/1.4.6 under Ubuntu 14.04. Consider the
following config:
server {
listen 8080 default_server;
root /usr/share/nginx/html;
autoindex on;
location /x/ {
At least update your openssl to 1.0.1j and try again.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,254028,254032#msg-254032
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Hi list,
we are seeing sporadic nginx errors "upstream prematurely closed
connection while reading response header from upstream" with nginx/1.6.2
which seems to be some kind of race condition.
For debugging purposes we only setup 1 upstream server on a public IP
address of the same server as ngin
Hello
I seem to have a bit of a problem. In my vhost's server {}; block, I have:
ssl_ciphers
EECDH+aRSA+AESGCM:EECDH+aRSA+AES:EDH+aRSA+AESGCM:EDH+aRSA+AES:DES-CBC3-SHA:!EXP:!CAMELLIA:!DSS:!MEDIUM:!LOW:!aNULL:!eNULL:!RC4;
ssl_prefer_server_ciphers on;
but for some reason this doesn't seem
could youe please send/gist your (anonymized) server {} configs?
one suggestions: enable 2 different access-logs for each server-black and
confirm requests to dom1.com go to the configured dom1.com and
requests to dom2.com go to the configured dom2.com.
once you are sure the requests go to th
46 matches
Mail list logo
