Feature #1546


Enhancements for mod_geoip

Added by spillgroup over 16 years ago. Updated 7 months ago.

3rd party
Target version:


I'm adding several patches for use with mod_geoip Docs:ModGeoip which allow:
  • A 'geoip.default_country_code' to be set when no matching country could be found.
  • A 'geoip.force_lowercase' to be set to force all returned country codes in lowercase.
  • Environment variables to be picked up and used in mod_redirect targets.

Example of combined usage:

geoip.db-filename              = "/usr/share/GeoIP/GeoIP.dat" 
geoip.memory-cache             = "enable" 

$HTTP["host"] =~ "^(www\.example\.com)(:[0-9]+)?$" {
        geoip.default_country_code = "us" 
        geoip.force_lowercase = "enable" 
        url.redirect = (
                "^/$"           => "http://%1%2/#GEOIP_COUNTRY_CODE#/",

This allows us to do in-server redirects based on GeoIP country codes. I know the patches aren't ideal (changes only done for country codes for example), but they might be useful to someone nevertheless. It beats using a PHP script, but some LUA might also do the trick. These patches are quite old, but have been in large scale production for over a year now without problems.


Related issues 1 (0 open1 closed)

Related to Bug #1976: geoip env + luaInvalidActions
Actions #1

Updated by stbuehler over 16 years ago

lighttpd-1.4.13... is a "little bit" old ;-)

  1. I think your patch split is not good - there are default_country parts in lowercase.patch.
    OTOH, I think both patches are good, so perhaps you don't need to split them.
  2. I don't think the redirect patch should be used - mod_magnet ;-)
  3. Why do you use snprintf with a const limit if you know the size of the buffer and the string?
  4. buffer_reset(x) shouldn't be necessary before a buffer_copy_*(x, *)
  5. Can you explain why you disabled mod_geoip_subrequest for p->handle_subrequest_start ?
  6. I think
    if (buffer_is_equal_string(du->key, CONST_STR_LEN("geoip.default_country_code"))) {
    could be
    else if (buffer_is_equal_string(du->key, CONST_STR_LEN("geoip.default_country_code"))) {

BTW: Does anyone know why the mod is not upstream? Does it contain blocking io-code?

Actions #2

Updated by spillgroup over 16 years ago

This was one of the first changes done by our (external) development team to the Lightty code. Sorry if the quality is not that good. Regarding the use of mod_magnet instead of mod_redirect: wouldn't that impose a lot more overhead?

Actions #3

Updated by stbuehler almost 16 years ago

  • Target version changed from 1.4.20 to 1.4.21
Actions #4

Updated by ism over 15 years ago

Any chance this makes it to 1.4.20? can keep running the patch manually but would be nice if it's part of the version

Actions #5

Updated by icy over 15 years ago

  • Target version changed from 1.4.21 to 1.4.22
  • Patch available set to Yes
Actions #6

Updated by stbuehler over 15 years ago

  • Target version changed from 1.4.22 to 1.4.23
Actions #7

Updated by stbuehler about 15 years ago

  • Target version changed from 1.4.23 to 1.4.x

There is no mod_geoip upstream yet.

Until this happens you could discuss this on Docs:ModGeoip

Actions #8

Updated by stbuehler over 14 years ago

  • Category changed from core to 3rd party
  • Assignee deleted (jan)
  • Target version deleted (1.4.x)
  • Missing in 1.5.x set to No
Actions #9

Updated by gstrauss about 8 years ago

  • Status changed from New to Wontfix

mod_geoip currently hooks subrequest_start, where the geoip info is then available to dynamic handlers such as mod_cgi, mod_fastcgi, mod_scgi.

The patches attached here move the hook to uri_clean, much earlier in the request process, effectively adding a database lookup to all requests, even for static content. Moving the hook earlier means that the geoip info is available to other handlers, besides the dynamic handlers, but adds a cost to everyone not using geoip for such purposes.

While these patches might be useful to some people, the patches are unlikely to be integrated.

As suggested above by stbuehler, if you need to do dynamic routing based on geoip info, then another option is to use mod_magnet to run a lua script to do a geoip lookup and url rewriting.

Actions #10

Updated by gstrauss almost 8 years ago

  • Related to Bug #1976: geoip env + lua added
Actions #11

Updated by gstrauss almost 3 years ago

  • ASK QUESTIONS IN Forums set to No

FYI: since lighttpd 1.4.45 (Jan 2017), lighttpd populates the request env on demand for dynamic modules, including mod_magnet, so info from mod_maxminddb (successor to mod_geoip) is available in mod_magnet

Actions #12

Updated by gstrauss 7 months ago

  • Status changed from Wontfix to Fixed

Since lighttpd 1.4.45, most features are available via mod_magnet and a custom lua script, and using mod_maxminddb (successor to mod_geoip)


Also available in: Atom