Bug #1184

a numeric tld

Added by Anonymous about 12 years ago. Updated almost 3 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Missing in 1.5.x:



this is a very minor problem, which probably will not affect most people .... dont know also if it's allowed as a domain, but ping doesn't mind :)

anyway, i usually add domains in /etc/hosts for projects i work on locally (format of project.project_name)... i had a project which a name which started with numbers (something like project.1man) ... configuring this virtualhost in lighttpd will result a 400 error... changing to 1man.project works (which is what i did eventually) :) ...

Associated revisions

Revision b47494d4 (diff)
Added by gstrauss about 3 years ago

[config] opts for http header parsing strictness (fixes #551, fixes #1086, fixes #1184, fixes #2143, #2258, #2281, fixes #946, fixes #1330, fixes #602, #1016)

server.http-parseopt-header-strict = "enable"
server.http-parseopt-host-strict = "enable" (implies host-normalize)
server.http-parseopt-host-normalize = "disable"

defaults retain current behavior, which is strict header parsing
and strict host parsing, with enhancement to normalize IPv4 address
and port number strings.

For lighttpd tests, these need to be enabled (and are by default)
For marginally faster HTTP header parsing for benchmarks, disable these.

To allow
- underscores in hostname
- hypen ('-') at beginning of hostname
- all-numeric TLDs
server.http-parseopt-host-strict = "disable"

"lighttpd doesn't allow underscores in host names"
"hyphen in hostname"
"a numeric tld"
"Numeric tld's"
"Bad Request"
"400 Bad Request when using Numeric TLDs"

To allow a variety of numerical formats to be converted to IP addresses
server.http-parseopt-host-strict = "disable"
server.http-parseopt-host-normalize = "enable"

"URL encoding leads to "400 - Bad Request""
"400 Bad Request when using IP's numeric value ("ip2long()")"

To allow most 8-bit and 7-bit chars in headers
server.http-parseopt-header-strict = "disable" (not recommended)

"Russian letters not alowed?"
"header Content-Disposition with russian '?' (CP1251, ascii code 255) causes error"



Updated by Anonymous almost 12 years ago

Replying to anonymous:

this is a very minor problem, which probably will not affect most people .... dont know also if it's allowed as a domain, but ping doesn't mind :)

It does happen to be true that it isn't valid for a tld to begin with a number.


Updated by moo almost 12 years ago

paste your config here inside

it would be nice if you make it simple yet reproducable before pasting here


Updated by icy over 10 years ago

  • Status changed from New to Fixed
  • Resolution set to invalid

As the anonymous commenter already said: tlds in your format are invalid, change your hostnames :)


Updated by stbuehler over 10 years ago

  • Status changed from Fixed to Invalid

Updated by rmxz over 9 years ago

  • Status changed from Invalid to Reopened

While it's technically true that there are no TLDs starting with numbers today, it is somewhat annoying. A fair number of companies use .companyname as a TLD for their intranets; and this makes lighttpd a poor fit for those that start with numbers.

If I were to submit a patch supporting TLDs that start with any alpha-numeric number for intranets like these, might this feature be reconsidered?

Conversely, lighttpd does support TLDs that end in numbers - though no such TLDs exist either. Should I submit a patch that rejects those?


Updated by nitrox over 9 years ago

  • Status changed from Reopened to Invalid
  • Missing in 1.5.x set to No

If lighty behaves like this, the next one screams lighty is not compliant. So where should this lead too? Just because sth. might be possible does not proof its the right thing to do. The "fix" is there -> use proper hostnames.


Updated by rmxz over 9 years ago

So would you guys also want a patch to exclude TLDs that have digits after the first character?


Updated by stbuehler over 9 years ago

  • Status changed from Invalid to Reopened
  • Target version deleted (1.5.0)

I think we could discuss whether we should check the hostname at all for such characteristics - perhaps we could simplify the checks.

  • Which characters should be allowed? The rfc even allows escaped characters (rfc 2396) - should we unescape it before checking?
    I think the basic regex looks like ([a-zA-Z0-9_~.!$&'()*+,;=\-]|%[0-9a-fA-Z][0-9a-fA-Z])+
    I guess [a-zA-Z0-9_.\-]+ should be enough, but perhaps there are good arguments for other characters.
  • Which substrings should be forbidden? ".." is a pretty obvious example imho, but are there more?

Updated by rmxz over 9 years ago

One more use-case that might be convenient if this check would be made more liberal, would be letting users access http://1st-web-server/ where '1st-web-server' is the hostname of a machine in the same domain that they're in. Currently it gives a 400 error too.

I'm not totally sure, but I think the relevant RFCs suggest
this "may" be allowed, by appending a domain name?

In this case, I think the relevant RFC is:
"Host request-header....(generally an HTTP URL as described in section 3.2.2)"
"... MAY add its domain to the host name it received. "


Updated by gstrauss about 3 years ago

  • Status changed from Reopened to Patch Pending
  • Target version set to 1.4.40

Updated by gstrauss almost 3 years ago

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

Also available in: Atom