I know nginx 1.7.4 fixes a bug about DNS resolver, but i do not quite
understand why this would lead to a request hang, Because there is a
timeout handling, at a specified time if there is no response the timeout
callback will be called，so why here can lead to request hang，
Could someone show me a
Hi
It seems that if I have 2 server {} sections, one with spdy enabled and
one without, spdy is still accepted on the second
server
{
server_name "";
listen 80;
listen 443 ssl spdy;
}
server
{
server_name "something.com";
listen 80;
listen 443 ssl
Setting:
proxy_ssl_verify_depth 2;
Fixed the issue. Can somebody explain why this is needed and why the default
setting is 1? I am using a standard wildcard SSL certificate from GoDaddy.
Thanks
Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,252518,252620#msg-252620
_
Hi
Tested 1.6.1 and 1.7.4
Speed is back to normal
Many thanks!
Richard
On 16/08/14 23:19, Valentin V. Bartenev wrote:
On Saturday 16 August 2014 01:27:19 Richard Kearsley wrote:
attached
Thank you for the report.
Please, try the following patch:
diff -r f1e05e533c8b src/http/ngx_http_reques
On Saturday 16 August 2014 01:27:19 Richard Kearsley wrote:
> attached
Thank you for the report.
Please, try the following patch:
diff -r f1e05e533c8b src/http/ngx_http_request.c
--- a/src/http/ngx_http_request.c Thu Jul 31 13:59:37 2014 +0400
+++ b/src/http/ngx_http_request.c Sun Aug
hello
i don't know how to add this code
=
rewrite "^/([0-9A-Za-z]{12})(\/.+|\.html?|)$"
/dl?op=download1&id=$1&fname=$2 last;
rewrite "^/embed-([0-9A-Za-z]{12})\.html$"
YEP thank you :
> The matching is performed against a normalized URI, after decoding the text
> encoded in the “%XX” form, resolving references to relative path components
> “.” and “..”, and possible compression of two or more adjacent slashes into a
> single slash.
so i do not have to put //
On Aug 16, 2014 6:22 PM, "Ronald Van Assche" wrote:
>
> NICE : it works
>
> more complicated one :
>
> /ue//ue/data/filename => /ue/data/filenam
> there is 2 / in the URL.
>
> location ^~ /ue//ue/ {
> rewrite ^/ue(/ue/.*) $1 permanent;
> }
>
> does not work :o(
>
>
try re
Hello,
The error comes from OpenSSL.
>From its name, I wouldsay the constant being check is one that OpenSSL sets
during handshake.
>From its name too, I wouls say this applies to a SSLv3 handshake. OpenSSL
has a corresponding TLSv1 constant named DTLS1_SEND_SERVER_KEY_EXCHANGE.
Seems like a bug,
NICE : it works
more complicated one :
/ue//ue/data/filename => /ue/data/filenam
there is 2 / in the URL.
location ^~ /ue//ue/ {
rewrite ^/ue(/ue/.*) $1 permanent;
}
does not work :o(
Le 16 août 2014 à 10:52, Edho Arief a écrit :
>>
> location ^~ /us/us/ {
> rewr
On Sat, Aug 16, 2014 at 5:27 PM, Ronald Van Assche wrote:
> I want to redirect /us/us/directory/filename to the /us/directory/filename
> directory on my Nginx server.
>
> but this
>
> if ( $request_filename ~ /us/us/.+ ) {
> rewrite ^(.*) http://mysiteurlt/us/$1 permanent;
Shouldn't the /us/ be removed in the rewrite? what does the logfile say
where it is trying to locate to?
Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,252606,252607#msg-252607
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/m
I want to redirect /us/us/directory/filename to the /us/directory/filename
directory on my Nginx server.
but this
if ( $request_filename ~ /us/us/.+ ) {
rewrite ^(.*) http://mysiteurlt/us/$1 permanent;
}
wont work.
How can i redirect or rewrite such url ?
_
Hello,
I may have missed something, but it was to my understanding that nginx
continuously send data to clients, thus fill up buffers whil the client
empties it at the same time (FIFO).
Thus, to me, backend upload was stopping when the allocated buffer(s)
was(were) full, waiting for space being av
14 matches
Mail list logo
