Hello, I have ngnix installed to serve up to websites. The first one is
behind is behind SSL and should redirect everything to https://EXAMPLE1.com.
This works perfectly as for the second website, its only being hosted on
http. All www traffic should redirect to non-www but it fails.
Here is my ng
Hello,
I have just 1 backend server being reverse-proxied through nginx. The access
log lists this one request for which the $upstream_addr has the same ip:port
twice. Is this a bug ?
:::10.255.255.248:51947 - - [18/Feb/2015:19:52:43 -0600] "GET / HTTP/1.1"
302 454 "-" "Mozilla/5.0 (Macin
On Tue, Feb 17, 2015 at 06:26:59PM -0500, dansch wrote:
Hi there,
> I tried your examples and they work very well.
> In the next days I will test it more extensive.
Good to hear, thanks.
> > >
> (track|include|img|template|picture|filearchive|content|robots\.txt|favicon\.ico)($|/)
> > > - [
On Tue, Feb 17, 2015 at 09:30:46PM -0500, Ben Johnson wrote:
> On 2/16/2015 3:52 PM, Francis Daly wrote:
Hi there,
> > ...and draw a picture of what happens when a client sends a 1MB upload
> > to nginx, and nginx sends it via proxy_pass to an upstream. That should
> > show you why it fails.
> A
I can second the fact FreeBSD + nginx is a rocking combo. We've been
running that for years under ever increasing traffic and it only requires a
few basic adjustments to the OS, even fewer in 10 since a lot of system
defaults were cranked up for modern times. Our current hardware handling
ngin
> Am 18.02.2015 um 16:56 schrieb ragavd :
>
> Hi,
> We are configuring the NGINX as a reverse proxy. We are expecting some 100
> concurrent users or connections/sessions to be active at any given moment of
> time. Right now the server is acting as a reverse proxy for only one
> application. These
Hi, I have a very simple website which could benefit from enabling cgi
caching. However, occasional updates are made to the site, exclusively
via a POST request.
For my simple purposes it would be sufficient to expire the entire cache
on any POST request (few hundred pages cached). How might
On Wednesday 18 February 2015 17:57:13 Daniël Mostertman wrote:
[..]
> What am I doing wrong, if anything? And if I can avoid using "if" like
> that, I'd obviously prefer that.
>
You can avoid it by using the map directive and a variable
as the add_header value.
Like this:
map $http_user_age
Hi again,
And ugh, yet again realising what I did wrong right after hitting "send":
Daniël Mostertman schreef op 18-2-2015 om 17:57:
tl;dr: I want do have an add_header inside an if {}. nginx 1.7.10
won't let me.
Because I didn't put the if inside a location.
According to both http://wiki.ngi
Hi!
I'm currently running 1.7.10 mainline straight from the nginx.org
repository.
We are hosting an application that needs to be accessible to Internet
Explorer users, in addition to all other *normal* browsers.
tl;dr: I want do have an add_header inside an if {}. nginx 1.7.10 won't
let me.
> [...]
>> Hi Maxim,
>>
>> Understood. Apart from the fact what SPDY can mean for someone specific.
>> There is a flaw in and which prevents "tcp_nodelay" in Nginx 1.6. to
>> function correctly.
>>
>> How to fix that.
>>
> There are several options:
>
> - you can backport 1.7 diff to 1.6;
>
> - you
[...]
> Hi Maxim,
>
> Understood. Apart from the fact what SPDY can mean for someone specific.
> There is a flaw in and which prevents "tcp_nodelay" in Nginx 1.6. to
> function correctly.
>
> How to fix that.
>
There are several options:
- you can backport 1.7 diff to 1.6;
- you can use 1.7 in
> On 2/18/15 6:57 PM, rik...@deds.nl wrote:
>>> On 2/18/15 5:42 PM, rik...@deds.nl wrote:
You can't optimize a site to the max without SPDY.
>>>
>>> That's doesn't match our experience.
>>>
>>> Also, enabling SPDY doesn't make your site faster automagically. It
>>> is not a silver bullet.
>>>
On 2/18/15 6:57 PM, rik...@deds.nl wrote:
>> On 2/18/15 5:42 PM, rik...@deds.nl wrote:
>>> You can't optimize a site to the max without SPDY.
>>
>> That's doesn't match our experience.
>>
>> Also, enabling SPDY doesn't make your site faster automagically. It
>> is not a silver bullet.
>>
>> --
>> M
> On 2/18/15 5:42 PM, rik...@deds.nl wrote:
>> You can't optimize a site to the max without SPDY.
>
> That's doesn't match our experience.
>
> Also, enabling SPDY doesn't make your site faster automagically. It
> is not a silver bullet.
>
> --
> Maxim Konovalov
> http://nginx.com
>
> __
Hi,
We are configuring the NGINX as a reverse proxy. We are expecting some 100
concurrent users or connections/sessions to be active at any given moment of
time. Right now the server is acting as a reverse proxy for only one
application. These concurrent users will connect predominantly between 6:0
On 2/18/15 5:42 PM, rik...@deds.nl wrote:
> You can't optimize a site to the max without SPDY.
That's doesn't match our experience.
Also, enabling SPDY doesn't make your site faster automagically. It
is not a silver bullet.
--
Maxim Konovalov
http://nginx.com
__
> On Wednesday 18 February 2015 00:41:34 rik...@deds.nl wrote:
>> Dear,
>>
>> While searching for Nginx optimize patches:
>>
>> https://josephscott.org/archives/2014/12/nginx-1-7-8-fixes-200ms-delay-with-spdy/
>>
>> Came to my attention.
>>
>> Can anyone confirm if the '200ms Delay With SPDY' probl
On Wednesday 18 February 2015 00:41:34 rik...@deds.nl wrote:
> Dear,
>
> While searching for Nginx optimize patches:
>
> https://josephscott.org/archives/2014/12/nginx-1-7-8-fixes-200ms-delay-with-spdy/
>
> Came to my attention.
>
> Can anyone confirm if the '200ms Delay With SPDY' problem also
19 matches
Mail list logo
