On Thu, May 01, 2014 at 02:07:49AM -0400, nrahl wrote:
Hi there,
> This is the entire config now:
>
> location ^~ /wordpress/ {
>fastcgi_pass unix:/var/run/php5-fpm.sock;
> }
That says "talk fastcgi to that socket", but nothing useful is sent on
that connection because you have no fastcgi_p
Hi,
We are also facing the same issue ,have any one faced the same problem of
getting blank pages with 200 status code when using nginx as reverse proxy
to jboss 7 ? any help/suggestion on this are very much appreciated.
Regards,
Chris
Posted at Nginx Forum:
http://forum.nginx.org/read.php?2
Hi,
On Thu, 2014-05-01 at 02:07 -0400, nrahl wrote:
> Ok, at this point I have removed everything from the config just to try and
> get the most basic thing working.
>
> This is the entire config now:
>
> location ^~ /wordpress/ {
>fastcgi_pass unix:/var/run/php5-fpm.sock;
> }
>
> location
Ok, at this point I have removed everything from the config just to try and
get the most basic thing working.
This is the entire config now:
location ^~ /wordpress/ {
fastcgi_pass unix:/var/run/php5-fpm.sock;
}
location / {
return 403;
}
That's all the location blocks.
What happens:
1. G
Hello!
On Wed, Apr 30, 2014 at 03:04:11AM -0400, kay wrote:
[...]
> So it seems that error_page 405 /error.html rewrites $request_method
Yes, redirection a request to an error page implies changing the
request method to GET (unless it's HEAD). It's required to
properly return error page. Mu
according to w3techs, nginx is now #1 on the top 1000 list of websites
and according to some perftests we did on our side, 1.6.0 seems to be
10% faster than 1.4; WELL DONE, nginx-team, and thanx for all the support
http://w3techs.com/technologies/cross/web_server/ranking
lyrics somewhat unrelat
On 30 Apr 2014 05:56, "Joydeep Bakshi"
wrote:
>
> Hello Maxim,
>
> Presently I have configured separate access & error log for each & every
nginx vhost. I wonder if there is other alternative which can log all
vhosts into a common access & error log and later split them according to
vhost for ea
Hi,
>> The fix is already in OpenBSD [4], Debian and Ubuntu will probably ship the
>> patch soon, also see [5] and [6].
>
> Oh, cool, that's good news that it's upstream then. Getting the patch
> to apply is a piece of cake. I was more worried about what would happen
> for the next libssl up
nginx from official repository:
nginx -V
nginx version: nginx/1.6.0
built by gcc 4.7.2 (Debian 4.7.2-5)
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx
--conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log
--http-log-path=/var/log/
On Tue, Apr 29, 2014 at 11:33:57PM -0400, Nick Rahl wrote:
Hi there,
> >That's not what ^~ means.
>
> The manual says, "If the longest matching prefix location has the
> "|^~|" modifier then regular expressions are not checked". Which
> means that a ^~ location will have a higher priority than a
user nginx;
worker_processes 1;
error_log /var/log/nginx/error.log warn;
pid/var/run/nginx.pid;
events {
worker_connections 1024;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
# LET'S LOG $request_method #
log_format main '$r
11 matches
Mail list logo
