Support Handshake TLD's

[eskimo]

This solves a problem with people who use apache and are using a TLD on the handshake protocol. On handshake it is perfectly valid for a TLD to start with a number, or even just be a single digit. This change won't break anything for existing ICANN users, but will allow handshake users to use apache.

If you aren't aware of handshake there have been some significant milestones lately that show the growth of handshake such as opera adding support, namecheap buying namebase.io and now selling handshake SLD's on namecheap.com.

Edit: After reading RFC it appears my change brings apache up to RFC standards rather than breaking them as I thought.

One aspect of host name syntax is hereby changed: the restriction on the first character is relaxed to allow either a letter or a digit. Host software MUST support this more liberal syntax.

[covener]

There is some background in rejected RFC 1123 errata that talks about the ambiguity/intent of the special rules for TLD: https://www.rfc-editor.org/errata/eid1353 that cl

Can you show an example FQDN the server is meant to accept? Is there any ambiguity with an IP address representation possible?

[eskimo]

Lets say example.3d.

As for the IP question, I suppose it would be possible, but I don't think anyone would do it. A popular TLD available for handshake names is .1, which I guess someone could own the SLD 1.1 and end up making something like 1.1.1.1. While that might technically be valid, It would be pretty ridiculous and I'm sure that person wouldn't expect it to work as a domain.

[rithvikvibhu]

I'd like to add that browsers already accept this as a valid domain name. Some examples:

	resolved as	value	desc
3d	domain ✅	3d	alnum bare tld
example.3d	domain ✅	example.3d	alnum subdomain on alnum tld
3	nothing	N/A	numeric bare tld
example.3	nothing	N/A	alnum subdomain on numeric tld
3.3d	domain ✅	3.3d	numeric subdomain on alnum tld
3.3	IPv4	3.0.0.3	numeric subdomain on numeric tld (which can be an IP)

This can be verified easily by typing in (for ex) http://example.3d in the address bar and seeing the first result:

I haven't dug into chromium's source to confirm it in code though.

[NetOpWibby]

@covener Does this PR need more work or something?

[covener]

@royfielding any thought on this? strict_hostname_check() is called only from fix_hostname() which has this comment: https://github.com/apache/httpd/blob/trunk/server/vhost.c#L801

So i think the hole being punched here (to allow TLD beginning with a number) isn't risky.

[covener]

CI failure is related to the change t/apache/http_strict.t

# SENDING:
# GET http://0x7f.1/ HTTP/1.0\r\n\r\n
# expecting 400, got 200
not ok 133

Seems It was added with the initial big batch of Host headers tests for HTTPProtocolOptions.

[royfielding]

@covener this would be "someone else's code" ( see https://github.com/apache/httpd/commit/f726113d3346126b972776296131d5b1026ce807 ) but there is nothing sacred about TLDs these days. My guess is that ICANN changed those rules anyway and this patch would be fine, but I haven't tested it.

[eskimo]

I've compiled and tested my commit and can confirm that it does work as intended in terms of a TLD beginning with a number being able to be configured.