Hello everyone,
I have a little problem on hand, related to redirect loop for a specific
location:
server {
listen 192.168.1.2:443 spdy ssl default_server;
...
location ^~ /alpha {
return 301 https://www.domain.com$request_uri;
}
...
}
I would like to redirect URL's of this format:
https://www
I think it's a bug. Quote from spdy2 spec:
"Receivers of a PING frame should send an identical frame to the sender as
soon as possible (if there is other pending data waiting to be sent, PING
should take highest priority)."
Bahaa Aidi
Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,2402
Valentin V. Bartenev Wrote:
---
> On Monday 16 December 2013 08:08:31 kustodian wrote:
> > Hi,
> >
> > Nginx 1.4.0 added support for SPDY to the stable version, so my
> question is
> > why is SPDY not enabled in the packages from the Nginx offici
Thanks for the response Bahaa. Great information. Would you say the behavior
that nginx queues the ping reply and doesn't send it until it gets a
response from upstream is a bug? We've had to disabled SPDY until the double
request issue gets resolved. Hoping that SPDY protocol version 3 support in
I was trying to understand the fastcgi forwarding. The example shows:
server {
server_name .website.com;
listen 80;
root /home/website/www;
index index.html;
location / {
fastcgi_pass 127.0.0.1:9000;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_n
On 2013-12-21 10:53, Ruslan Ermilov wrote:
> It's the property of the Web application, not the server (nginx).
>
> Please see section 3.1 of
> http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/37517.pdf
> for a less formal explanation of when it's safe to enable TFO:
I noticed the same behavior when sending long running requests (>10secs)
from chrome with nginx running as a reversy proxy with spdy enabled. What
happens is that chrome sends a PING frame, then sends the request, then if
it doesn't get a PING reply it will close the connection and resend the
reque
