We have a setup in which nginx proxypass is working fine for tomcat like
this:
server {
listen 80;
server_name app.geo.com;
location /app {
proxy_pass https://192.168.1.100:8080/app;
}
Now while accessing http://app.geo.com/app is working fine.
Now we need to access the same app
Hi Steve,
that's a lot of apache nonsense ;) that you shouldn't need
check out:
http://nginx.org/en/docs/http/converting_rewrite_rules.html
another useful link with great commenting:
https://blog.engineyard.com/2011/useful-rewrites-for-nginx/
-Payam
On 2014-03-20, 9:44 PM, Steve Holdoway wrot
I'm tryiing to migrate a site that uses codeigniter behind modx to draw
pages, and this is the block that breaks the site when I remove it
from .htaccess...
RewriteRule ^$ home [L]
RewriteCond %{HTTP_HOST} ^(?:www\.)?([^\.]*)\..*$ [NC]
RewriteCond %{REQUEST_URI} !^/?$
On Thu, Mar 20, 2014 at 04:33:35PM -0400, drhowarddrf...@charter.net wrote:
Hi there,
> I was just typing what I think may be the reason. That other location
> blocks may be picking this up and eventually returning a 404 but, with
> that block in there, the image and css requests are getting "h
I was just typing what I think may be the reason. That other location
blocks may be picking this up and eventually returning a 404 but, with
that block in there, the image and css requests are getting "handled",
ie, nothing is done to them at all, and then retrieved from their proper
director
On Thu, Mar 20, 2014 at 04:10:29PM -0400, drhowarddrf...@charter.net wrote:
Hi there,
> location ~*
> ^.+\.(css|js|jpg|jpeg|gif|png|ico|gz|svg|svgz|ttf|otf|woff|eot|mp4|ogg|ogv|webm|pdf)$
>
> {
> }
>
> Today, I deleted that block and now the images, css and javascript files
> are all returne
I'm new to nginx and had this in my conf file which I had copied some
time ago but never filled it in and continued building a test page with
images, css and javascript:
location ~*
^.+\.(css|js|jpg|jpeg|gif|png|ico|gz|svg|svgz|ttf|otf|woff|eot|mp4|ogg|ogv|webm|pdf)$
{
}
Today, I deleted
Thanks Igor for that clear and concise answer!
---
*B. R.*
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Hello Nginx users,
Now available: Nginx 1.5.12 for Windows http://goo.gl/TOFukx (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 availa
Hello Nginx users,
Now available: Nginx 1.4.7 for Windows http://goo.gl/KNRYGj (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 availab
Thanks for the quick answer! Good to know that you are going to add the
debuginfo package :)
Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,248527,248532#msg-248532
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listi
Hello!
On Thu, Mar 20, 2014 at 09:38:40AM +0530, Makailol Charls wrote:
> Hi,
>
> Is there some way to achieve this? I want to pass requests to backend based
> on cache status condition.
This is not something easily possible, as cache status is only
known after we started processing proxy_pass
On 20 Mar 2014, at 16:58, dompz wrote:
> I have a question to the nginx team - is there any chance for me to get the
> debugging symbols for the nginx-1.4.7-1.el6.ngx.x86_64.rpm from
> http://nginx.org/packages/rhel/6/x86_64/RPMS/? It seems the nginx-debug
> package contains a different binary,
I have a question to the nginx team - is there any chance for me to get the
debugging symbols for the nginx-1.4.7-1.el6.ngx.x86_64.rpm from
http://nginx.org/packages/rhel/6/x86_64/RPMS/? It seems the nginx-debug
package contains a different binary, so the symbols won't match the one from
the nginx
Thank you very much.
Sorry if my English causes mistakes, my native language is Spanish.
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
On Mar 20, 2014, at 12:28 , B.R. wrote:
> I am using the official Debian package (stable) and I noticed the service
> file, in its do_stop() function, sends SIGTERM to the master process.
>
> However, the docs say SIGTERM (and SIGQUIT) sent to the master process
> provokes a 'fast shutdown' whe
I am using the official Debian package (stable) and I noticed the service
file, in its do_stop() function, sends SIGTERM to the master process.
However, the docs say SIGTERM (and SIGQUIT) sent to the master process
provokes a 'fast shutdown' whereas SIGQUIT would provoke a 'graceful
shutdown'.
Wh
Have you tried to 'reload' the server by sending SIGHUP to the master
process? Or if this is not enough try upgrading it on the fly or restart
(stop/start) it.
Nginx, as any process, cannot detect system changes such as this ones on
its own...
If you modiify your hardware environment, you need to
18 matches
Mail list logo
