Project

General

Profile

Feature #2706

Matching IPv6 addresses with $HTTP["remoteip"]

Added by ef over 1 year ago. Updated about 1 year ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
Category:
core
Target version:
Start date:
2016-01-19
Due date:
% Done:

100%

Estimated time:
Missing in 1.5.x:

Description

$HTTP["remoteip"] doesn't match on IPv6 addresses.
It may also be useful for it to match v6-mapped IPv4 addresses.
I supplied a patch to do both in #385, but was asked to open a new bug.
I understand that the preferred configuration is to use bindv6only, but some installments (not mine) may be stuck with v6-mapped addresses so silently matching them with dotted-quad addresses may come handy to those people.
The attached patch lacks MS-Windows support.

remoteip-v6 (3.66 KB) remoteip-v6 patch fo allow $HTTP[remoteip] compares to v6 and v6-mapped v4 addresses ef, 2016-01-19 15:32

Related issues

Related to Bug #385: Enabling ipv6 makes matching subnets with $HTTP["remoteip"] inoperable.Invalid

Associated revisions

Revision bed63b79 (diff)
Added by gstrauss about 1 year ago

[core] support IPv6 in $HTTP["remote-ip"] CIDR cond match (fixes #2706)

x-ref:
"Matching IPv6 addresses with $HTTP["remoteip"]"
https://redmine.lighttpd.net/issues/2706

github: closes #52

History

#1 Updated by gstrauss over 1 year ago

Read through patch and it looks sane to me.

ef, would you consider writing a few tests in tests/*.t to validate the patch? Thanks.

#2 Updated by stbuehler over 1 year ago

  • Target version set to 1.4.x

#3 Updated by stbuehler over 1 year ago

  • Related to Bug #385: Enabling ipv6 makes matching subnets with $HTTP["remoteip"] inoperable. added

#4 Updated by gstrauss over 1 year ago

ef: would you consider writing a few tests in tests/*.t to validate the patch? Thanks.

#5 Updated by ef over 1 year ago

gstrauss wrote:

would you consider writing a few tests in tests/*.t to validate the patch?

I may consider that, but I'm neither familiar with lighttpd's test framework nor will I have time left to do that anytime soon, sorry.

#6 Updated by gstrauss over 1 year ago

  • Tracker changed from Bug to Feature

The attached patch lacks MS-Windows support.

Would you provide a link or two, or a quick explanation why? Thx.

#7 Updated by ef over 1 year ago

gstrauss wrote:

Would you provide a link or two

I don't understand. A link to what?

or a quick explanation why?

Because I don't know how to write that support.
There's an #ifdef __WIN32 in the code and the true branch uses some inet_addr() function (while the false branch used inet_aton() and now uses inet_pton()).
I have no idea how to parse (nor any chance to test) network addresses on MS-Windows.

#8 Updated by gstrauss over 1 year ago

Windows provides inet_pton() in versions of Windows after Windows XP, so that patch needs to be adjusted for that. I don't think we should worry about supporting Windows XP or earlier.

#9 Updated by ef over 1 year ago

gstrauss wrote:

so that patch needs to be adjusted for that.

By someone with access to an MS-Windows machine, probably.

#10 Updated by gstrauss about 1 year ago

  • Status changed from New to Patch Pending
  • Target version changed from 1.4.x to 1.4.40

#11 Updated by gstrauss about 1 year ago

  • Status changed from Patch Pending to Fixed
  • % Done changed from 0 to 100

Also available in: Atom