Hello Nginx
Before writing this I have checked the meaning of the 499 error code as
result of that the client closed the connection before the server
answered the request. Thats clear as water.
PROBLEM: Iam measuring the execution time of the requests, and I see
that in general for all site
On Tuesday 15 April 2014 14:37:17 nxspeed wrote:
> Have you looked @ http://tengine.taobao.org/document/dso.html
>
http://mailman.nginx.org/pipermail/nginx/2012-September/035405.html
wbr, Valentin V. Bartenev
___
nginx mailing list
nginx@nginx.org
h
Have you looked @ http://tengine.taobao.org/document/dso.html
Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,123868,249317#msg-249317
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
hi,
what is your os (name and version)?
where do you have the ciphers from bwt?
i'd suggest you test the tls-version yourself with testssl.sh
https://bitbucket.org/nginx-goodies/testssl.sh
(note: you need a current openssl-version on the machine you test
from)
regards,
mex
Posted at Ngin
On Tuesday 15 April 2014 12:50:35 nanne wrote:
> This is somewhat of an old one, but has there been any change on account of
> this possible bug? We have currently shut down SPDY to avoid this, but at
> the cost of... well.. shutting down SPDY ;)
>
> I have made a serverfault-topic about this by t
On an empty VPS hosting (Ubuntu 13.10 x64), I managed to run the base
iRedMail installation with Apache2 and LDAP and my roundcubemail was
accessible at:
`https://www.mydomain.com/mail`
then I installed NginX, shutdown Apache2, reconfigured iRedMail (without
adding any extra A record in the DNS
This is somewhat of an old one, but has there been any change on account of
this possible bug? We have currently shut down SPDY to avoid this, but at
the cost of... well.. shutting down SPDY ;)
I have made a serverfault-topic about this by the way but currently the only
things in there are my deta
I should clarify the the default for ssl_protocols is fine, to my
environment since we need to support SSLv3, if you don't I suggest make it
safer:
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
On Tue, Apr 15, 2014 at 2:31 PM, Miguel Clara wrote:
>
> I have an nginx 1.5 install where I don't set the ss
I have an nginx 1.5 install where I don't set the ssl_protocols, because,
the defaults are fine:
---> "Since versions 1.1.13 and 1.0.12, nginx uses “ssl_protocols SSLv3
TLSv1 TLSv1.1 TLSv1.2” by default."
This is what I have find to be the best for ciphers, SSLLABS seems to like
it, I would even
Hello
I`m struggling with enabling tls1.1 and tls1.2. Some info:
NGINX:
# nginx -V
nginx version: nginx/1.5.13
built by gcc 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu9)
TLS SNI support enabled
configure arguments: --prefix=/usr/local/nginx/1.5.13
--conf-path=/etc/nginx/nginx.conf --error-log-path=/var
Hello!
On Tue, Apr 15, 2014 at 03:52:04AM -0400, trapni wrote:
> Hey, I just found you via Google as I was trying to find out why . Nginx
> is not supporting dynamic loading of modules, for the very obvious issues
> the other posters seem to have too.
>
> However, Maxim, you claim, that one
Hello,
has anyone considered this simple workaround for BREACH and
gzip-compression, i.e. randomly interspersed flush()-es during compression?
https://github.com/wnyc/breach_buster
It would be compatible with all clients, and should be fairly easy to
implement in nginx (for nginx hackers).
Of cour
Hello!
On Mon, Apr 14, 2014 at 03:03:54PM -0400, itpp2012 wrote:
> Fyi. if you are running a ssl tunnel like stunnel with openssl 0.9.x, this
> attack is logged as "SSL3_GET_RECORD:wrong version number" as opposed to no
> nginx/openssl logging.
>
> If you have logging going back 2 years and you
Hey, I just found you via Google as I was trying to find out why . Nginx
is not supporting dynamic loading of modules, for the very obvious issues
the other posters seem to have too.
However, Maxim, you claim, that one reason is performance. While performance
of course matters, I'd like to kno
14 matches
Mail list logo
