Lighty does not understand IPv4 compatible IPv6
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
[core] accept dots in ipv6 addresses in host header (fixes #2359)
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@2811 152afb58-edef-0310-8abb-c4023f1b3aa9
#3 Updated by kindkaktus about 5 years ago
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.
Also available in: Atom