Project

General

Profile

Actions

Bug #2359

closed

Lighty does not understand IPv4 compatible IPv6

Added by kindkaktus over 12 years ago. Updated over 12 years ago.

Status:
Fixed
Priority:
Normal
Category:
core
Target version:
ASK QUESTIONS IN Forums:

Description

Lighty does not understand IPv4 compatible IPv6 addresses and returns HTTP 400 (Bad Request)

Example with site-local IPv6 fd7c::192.168.1.2 (fd7c::c0a8:1a3 in HEX format)

# wget [fd7c::192.168.1.2]:3000
# tail -n 1 /var/log/lighttpd/access.log
fd7c::c0a8:1a3 - - [27/Oct/2011:04:07:21 -0700] "GET / HTTP/1.0" 400 349 "-" "Wget/1.12 (linux-gnu)" 

Notice that hostname does not appear in the log.

At the same time lighty successfully handles the same IP written in HEX (IPv6) format:

# wget [fd7c::c0a8:1a3]:3000
# tail -n 1 /var/log/lighttpd/access.log
fd7c::c0a8:1a3 [fd7c::c0a8:1a3]:3000 - [27/Oct/2011:04:07:33 -0700] "GET / HTTP/1.0" 200 66 "-" "Wget/1.12 (linux-gnu)" 

The problem lives in request_check_hostname() function in request.c where only ':' and HEX numbers are accepted for IPv6.

Reproduced in lighty-1.4.29 (CentOS-6.0), also checked in the source tree - the bug still exists in the latest revision 2786 of request.c

Actions #1

Updated by kindkaktus over 12 years ago

BTW Apache does not have such a problem

Actions #2

Updated by darix over 12 years ago

and this matters why?

Actions #3

Updated by kindkaktus over 12 years ago

darix wrote:

and this matters why?

First using non-hex notation like ::192.168.1.2 is more typical for these kind of IPv6 addresses, thus making them user-friendlier.
Second these kind of addresses are quite frequently used since thay allow IPv6-enabled hosts to talk over legacy IPv4 infrastructure.
Finally the fix seems trivial: just be more permissive in request_check_hostname() since the underlying OS network API understand both notations.

Actions #4

Updated by brad@comstyle.com over 12 years ago

kindkaktus wrote:

Second these kind of addresses are quite frequently used since thay allow IPv6-enabled hosts to talk over legacy IPv4 infrastructure.

IPv4 works just fine without the need for v4-mapped addresses.

Actions #5

Updated by kindkaktus over 12 years ago

wrote:

IPv4 works just fine without the need for v4-mapped addresses.

A typical scenario is IPv4 client talking to lighty bound to IPv6 wildcard address and described in RFC 4038 http://tools.ietf.org/html/rfc4038#page-9

Actions #6

Updated by stbuehler over 12 years ago

lighttpd uses IPV6_V6ONLY, so this is not going to happen (ipv4 connection to the ipv6 socket).

this still is certainly a bug, just not one with a high priority.

Actions #7

Updated by stbuehler over 12 years ago

  • Target version changed from 1.4.x to 1.4.30
Actions #8

Updated by stbuehler over 12 years ago

  • Status changed from New to Fixed
  • % Done changed from 0 to 100

Applied in changeset r2811.

Actions

Also available in: Atom