Try issuing the directive;
proxy_set_header
>proxy_set_header Host $host:$proxy_port;
Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,238933,238976#msg-238976
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo
After some more faffing with XSP4 and Web.config, I was at least able to
serve a 'Hello World' via TCP. So this proves that nginx and mono can work
together on my setup.
So in going back to the unix sockets, I still have the same problem. As
already suggested, this does look like a permissions i
On Sun, May 05, 2013 at 07:04:21AM -0400, zakaria wrote:
> Francis Daly Wrote:
Hi there,
> Thank you for confirm it.
> Its nginx bug #321 http://trac.nginx.org/nginx/ticket/321
Ah, good find -- I hadn't spotted that it was a "known issue".
> location ~ [^/]\.php(/|$) {
Just as another
OK, It appears I have been trigger-happy and wandered down a dead-end (my
apologies to everyone). I removed System.Configuration.dll from my
deployment and XSP ran (and was as happy as it can be).
I am now back to the bad gateway problem (502).
This tells me that the site's code is not the probl
OK, by removing all copies of \bin\System.Web.* from my app's path, I
whittled the exception down to this:
Handling exception type TypeInitializationException
Message is An exception was thrown by the type initializer for
System.Web.Configuration.WebConfigurationManager
IsTerminating is set to Tru
Hi everyone
I have made progress (of sorts). After lots of faffing, I got xsp2/4 to
work and have logged the following exception:
Handling exception type TargetInvocationException
Message is Exception has been thrown by the target of an invocation.
IsTerminating is set to True
System.Reflection.
On 7 May2013, at 20:23 , Richard Stanway wrote:
> Thanks for posting the configure script.
You can download srpm and/or debian source package from nginx.org and look at
configure options or change/rebuild it for your needs.
> Is there a reason why the geoip module is not compiled into the pa
Hello Nginx users,
Now available: Nginx 1.4.1 for Windows http://goo.gl/4kA8O (32-bit and
64-bit versions)
These versions are to support legacy users who are already using Cygwin
based builds of Nginx. Officially supported native Windows binaries are at
nginx.org.
Announcements are also availabl
> 2013/5/7 Sergey Budnevitch
>
>>
>> On 7 May2013, at 15:13 , Christian Bönning
>> wrote:
>>
>> > Thanks. But I would just like to know that before I actually start to
>> deploy something on our development/testing/staging/production environments
>> ... ;)
>>
>> % nginx -V
>> nginx version: ngin
Hello Nginx users,
Now available: Nginx 1.5.0 for Windows http://goo.gl/h2e8w (32-bit and
64-bit versions)
These versions are to support legacy users who are already using Cygwin
based builds of Nginx. Officially supported native Windows binaries are at
nginx.org.
Announcements are also availabl
Thank you Sergey. That helps.
Best regards,
Christian
2013/5/7 Sergey Budnevitch
>
> On 7 May2013, at 15:13 , Christian Bönning
> wrote:
>
> > Thanks. But I would just like to know that before I actually start to
> deploy something on our development/testing/staging/production environments
>
On 7 May2013, at 15:13 , Christian Bönning
wrote:
> Thanks. But I would just like to know that before I actually start to deploy
> something on our development/testing/staging/production environments ... ;)
% nginx -V
nginx version: nginx/1.5.0
TLS SNI support enabled
configure arguments: --
Hello!
On Tue, May 07, 2013 at 06:48:11AM -0400, Krupa wrote:
> There are no rewrite policies.
> location /gw_proxy {
> #internal;
> #resolver 8.8.8.8;
> proxy_http_version 1.1;
> proxy_pass http://50.112.76.185:9001;
> proxy_pass_reque
Hello!
Greg MacManus, of iSIGHT Partners Labs, found a security problem
in several recent versions of nginx. A stack-based buffer
overflow might occur in a worker process while handling a
specially crafted request, potentially resulting in arbitrary code
execution (CVE-2013-2028).
The problem af
Changes with nginx 1.4.1 07 May 2013
*) Security: a stack-based buffer overflow might occur in a worker
process while handling a specially crafted request, potentially
resulting in arbitrary code execution (CVE-2013-2028); the bug had
Changes with nginx 1.5.0 07 May 2013
*) Security: a stack-based buffer overflow might occur in a worker
process while handling a specially crafted request, potentially
resulting in arbitrary code execution (CVE-2013-2028); the bug had
Thanks. But I would just like to know that before I actually start to
deploy something on our development/testing/staging/production environments
... ;)
Best regards,
Christian
2013/5/7 Anton Yuzhaninov
> On 05/07/13 14:50, Christian Bönning wrote:
>
>> The issue in question currently is which
On 05/07/13 14:50, Christian Bönning wrote:
The issue in question currently is which parameters for ./configure are used to
build those packages?
run
nginx -V
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Hi,
I think about moving from custom compiled versions to Mainline Ubuntu
Packages provided at nginx.org/packages. The issue in question currently is
which parameters for ./configure are used to build those packages? is there
any documentation regarding which modules are built in? Or is there any
There are no rewrite policies.
location /gw_proxy {
#internal;
#resolver 8.8.8.8;
proxy_http_version 1.1;
proxy_pass http://50.112.76.185:9001;
proxy_pass_request_body off;
proxy_set_header Content-Length 0;
}
invoke
Hello!
On Tue, May 07, 2013 at 05:45:50AM -0400, Krupa wrote:
> I am using nginx as a reverse proxy. My requirement is nginx needs to pass
> the url passed by client as-is to the proxy server.
> I have set the proxy_pass to hostname:port without the uri part
> As per the docs ,If it is necessary
I am using nginx as a reverse proxy. My requirement is nginx needs to pass
the url passed by client as-is to the proxy server.
I have set the proxy_pass to hostname:port without the uri part
As per the docs ,If it is necessary to transmit URI in the unprocessed form
then directive proxy_pass should
Hello!
On Tue, May 07, 2013 at 03:40:02AM -0400, alexander_koch_log wrote:
> When compiling nginx with NGX_HTTP_CACHE and using upstream backends - are
> responses automatically cached in memory without the use of proxy_cache?
No.
--
Maxim Dounin
http://nginx.org/en/donation.html
Hi, Maxim
thanks for you replies.
i have already checked out the problem.
Yes ,the nginx will re-resolve the domains unless reload the configuration.
this is my problem.
because i am using Dynamic IP address.
thank you.
Daniel
Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,23
Hi,
When compiling nginx with NGX_HTTP_CACHE and using upstream backends - are
responses automatically cached in memory without the use of proxy_cache?
Thanks,
Alex
Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,238929,238929#msg-238929
__
25 matches
Mail list logo
