GEOIP context problem

There is a problem with current 0.8.x release of GEOIP although I assume
it has always not worked, where these variables:
fastcgi_param GEOIP_CITY_COUNTRY_CODE $geoip_city_country_code;
fastcgi_param GEOIP_CITY_COUNTRY_CODE3 $geoip_city_country_code3;
fastcgi_param GEOIP_CITY_COUNTRY_NAME $geoip_city_country_name;
fastcgi_param GEOIP_REGION $geoip_region;
fastcgi_param GEOIP_CITY $geoip_city;
fastcgi_param GEOIP_POSTAL_CODE $geoip_postal_code;
fastcgi_param GEOIP_CITY_CONTINENT_CODE $geoip_city_continent_code;
fastcgi_param GEOIP_LATITUDE $geoip_latitude;
fastcgi_param GEOIP_LONGITUDE $geoip_longitude;

do not work except inside the fastcgi_params file. The context is
suppose to work within http as per module documentation however setting
these variables
within http context ends up not setting them at all.

This is currently a major issue especially in freebsd where an upgrade
of version from port collections can wipe out fastcgi_params file each
time, leaving
any webserver relying on these variables in major trouble if they were
to forget to replace fastcgi_params file afterwards.

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,125449,125449#msg-125449

On Tue, Aug 31, 2010 at 12:18:13AM -0400, syle wrote:

fastcgi_param GEOIP_LONGITUDE $geoip_longitude;
to forget to replace fastcgi_params file afterwards.
Could you test following patch against current version of
ports/www/nginx-devel ?

Thank you.

Hello!

On Tue, Aug 31, 2010 at 12:18:13AM -0400, syle wrote:

fastcgi_param GEOIP_LONGITUDE $geoip_longitude;

do not work except inside the fastcgi_params file. The context is
suppose to work within http as per module documentation however setting
these variables
within http context ends up not setting them at all.

Most likely you attempted to do something like

http {
fastcgi_param …

server {

location … {
fastcgi_param …

}
}
}

This won’t work due to inheritance rules for array-type
directives, see here:

http://wiki.nginx.org/NginxHttpFcgiModule#fastcgi_param

“Directives set in current level clear any previously defined
directives for the current level.”

You have to define all fastcgi_param directives at the same level,
i.e.

location … {
fastcgi_param …
fastcgi_param …

}

or

http {
fastcgi_param …
fastcgi_param …

}

Maxim D.

Actually I’ll post one of my server directives so we can see if there is
any inheritance problems like
you suggested, i have about 50 server directives the same as this:
( I know it seems quite bloated but I didn’t read any way I could set
php and perl/cgi scripts outside of
server directivesfor all the vhosts)

server {
listen 80;#bind to ipv4
listen [::]:80; #bind to ipv6
server_name x.x.x;
root /xxx/xxx/xxx;
access_log /usr/nginx_logs/xxx_xxx_log main;
error_log /usr/nginx_logs/xxx_xxx_error;
index index.php index.pl index.html;
error_page 404 /xxx/xxx.pl;
error_page 500 502 503 504 /xxx/xxx.pl;
location ~ .php$ {
fastcgi_index index.php;
fastcgi_pass unix:/tmp/cgi2.sock;
fastcgi_param SCRIPT_FILENAME
$document_root$fastcgi_script_name;
include fastcgi_params;
}
location ~ .pl$ {
fastcgi_pass unix:/tmp/cgi.sock;
fastcgi_param SCRIPT_FILENAME
$document_root$fastcgi_script_name;
include fastcgi_params;
}
}

---- i do see params being set in location as you said would not work,
So are you saying i would have to add all those GEO_IP directives to all
50 server directives :frowning: perhaps maybe can suggest a way to move these
perl and php directives outside server directives into http context to
work with GEOIP? or I have to hope for a freebsd commit to stop removing
that file I suppose.

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,125449,125687#msg-125687

Hello!

On Tue, Aug 31, 2010 at 10:58:23AM -0400, syle wrote:

fastcgi_param GEOIP_CITY_COUNTRY_CODE3 $geoip_city_country_code3;
}
And you likely have “include fastcg_params;” in your locations
blocks. This is exactly what I was talked about. You have to
set all fastcgi_param’s at the same level.

Maxim D.

Thankyou for repliies, as far as freebsd guy, reading your patch just
suggests not removing fast fastcgi_params file which would be a nice
commit
till this is resolved.

Maxim:

I was doing strictly in http context as module was documented nothing
else and it was not recogised at all ie:

http {
#GEOIP, can parse ENV headers now for where they are located :slight_smile:
geoip_city /usr/local/share/GeoIP/GeoLiteCity.dat;

fastcgi_param GEOIP_CITY_COUNTRY_CODE $geoip_city_country_code;
fastcgi_param GEOIP_CITY_COUNTRY_CODE3 $geoip_city_country_code3;
fastcgi_param GEOIP_CITY_COUNTRY_NAME $geoip_city_country_name;
fastcgi_param GEOIP_REGION $geoip_region;
fastcgi_param GEOIP_CITY $geoip_city;
fastcgi_param GEOIP_POSTAL_CODE $geoip_postal_code;
fastcgi_param GEOIP_CITY_CONTINENT_CODE $geoip_city_continent_code;
fastcgi_param GEOIP_LATITUDE $geoip_latitude;
fastcgi_param GEOIP_LONGITUDE $geoip_longitude;

#virtual hosting---all server {} directives
include /usr/local/etc/nginx/vhosts/*;

}

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,125449,125670#msg-125670

Hello!

On Tue, Aug 31, 2010 at 11:38:38AM -0400, syle wrote:

listen       [::]:80; #bind to ipv6
    fastcgi_param  SCRIPT_FILENAME

---- i do see params being set in location as you said would not work,
So are you saying i would have to add all those GEO_IP directives to all
50 server directives :frowning: perhaps maybe can suggest a way to move these
perl and php directives outside server directives into http context to
work with GEOIP? or I have to hope for a freebsd commit to stop removing
that file I suppose.

As long as all fastcgi_param’s are identical in all locations -
you are free to move all of them to http level.

Alternatively - nothing stops you from using another include file
for these params.

Maxim D.

Sergey:

I will just do following for now, so maybe overwriting fastcgi_params
might not be such a bad thing on freebsd since we will always get
a new copy of anything that changes automatically, i’ve just thrown the
geoip values in another include as follows:

location ~ \.php$ {
    #fastcgi_pass   127.0.0.1:9000;
    fastcgi_pass  unix:/tmp/cgi2.sock;
    fastcgi_index  index.php;
    fastcgi_param  SCRIPT_FILENAME

$document_root$fastcgi_script_name;
include fastcgi_params;
include fastcgi_params_geoip;
}
location ~ .pl$ {
fastcgi_pass unix:/tmp/cgi.sock;
fastcgi_param SCRIPT_FILENAME
$document_root$fastcgi_script_name;
include fastcgi_params;
include fastcgi_params_geoip;
}

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,125449,125883#msg-125883

Unfortunately the location directive only works in server context, so
fastcgi_param SCRIPT_FILENAME is always going to loose
any http context defined vars for executing php and perl scripts,
basically where they are needed.

Would be nice to be able to set location in http context for those perl
and php scripts as I have them, making them server wide for vhosts.

I’ll take your other suggestion for now and just use another include
file so I stop having this issue with freebsd overwriting that file.

Thank-you.

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,125449,125881#msg-125881

Hi, syle.

Did you test my changes for www/nginx-devel port?
Does everything works fine for you?


Sergey A. Osokin
[email protected]
[email protected]

On Tue, Aug 31, 2010 at 10:43:38PM -0400, syle wrote:

    fastcgi_index  index.php;
    include        fastcgi_params_geoip;
}

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,125449,125883#msg-125883


nginx mailing list
[email protected]
http://nginx.org/mailman/listinfo/nginx


Sergey A. Osokin,
[email protected]
[email protected]

This really sucks. It’d be MUCH better if you could simply inherit the
fastcgi_param. I’ve now come across this a bunch of times with
different projects. It’d be nice for example to pass DEBUG 1 or DEBUG 0
to the fastcgi handler.

The documentation makes sense after you read it a bunch of times, but at
first read, it makes it seem like you can inherit portions of
fastcgi_param.

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,125449,143261#msg-143261

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs