Bug #385
Enabling ipv6 makes matching subnets with $HTTP["remoteip"] inoperable.
| Status: | Invalid | Start: | ||
| Priority: | Normal | Due date: | ||
| Assigned to: | - | % Done: | 0% |
|
| Category: | core | |||
| Target version: | - | |||
| Pending: | No |
Resolution: | invalid |
|
| Patch available: |
Description
When ipv6 is enabled, clients connecting via an ipv4 address are recorded in the accesslog with a ::ffff: in front of the ipv4 address. Here is an example line from my accesslog:
::ffff:147.210.96.15 - - -0800 "GET /linux/core/4/i386/os/repodata/repomd.xml HTTP/1.1" 200 1140 "-" "urlgrabber/2.9.6"
This seems to prevent matching of remote ip's via subnet. If I do:
$HTTPremoteip "127.0.0.1/8"
I never get a match, even from addresses from within that range.
Similarly, $HTTPremoteip "::ffff:127.0.0.1/8" also doesnt work.
The exact match: $HTTPremoteip == "::ffff:127.0.0.1" does work indicating that the ipv6 mess at the front is causing the problem.
This problem seems to go away when lighttpd is bound to an interface with no ipv6 address associated with it.
-- dandy
History
08/02/2008 10:35 PM - rm
This seems to prevent matching of remote ip's via subnet.
For simple cases (i.e. /24, /16 or /8) the subnet matching can be simulated using a regexp instead:
$HTTPremoteip =~ "^(192\.168\.0\.)" {
...this will match 192.168.0.*, basically a /24 network.
09/02/2008 12:47 AM - stbuehler
- Status changed from New to Fixed
- Resolution set to invalid
On some systems enabling ipv6 and binding to ANY means that ipv4 requests are mapped to ipv6, and there is no ipv6 subnet matching. not unexpected.