Route hostname validation should warn about underscores (RFC 952/1123 violation)

Issue

When creating a route via the Cloud Controller API (V3), hostnames containing underscores are accepted without any warning, even though underscores are not valid characters in DNS hostnames per RFC 952 and RFC 1123. This can lead to TLS hostname verification failures in clients that strictly implement wildcard certificate matching per the DNS character set.

Context

The hostname validation regex in both app/messages/route_create_message.rb (line 28) and app/models/runtime/route.rb (line 118) uses:

/\A([\w-]+|\*)?\z/

Ruby's \w character class expands to [a-zA-Z0-9_], which explicitly includes underscores. The accompanying error message even documents this:

must be either "*" or contain only alphanumeric characters, "_", or "-"

This is inconsistent with other parts of the Cloud Foundry ecosystem that already treat underscores as invalid:

• cf push automatically converts underscores to hyphens when generating routes from app names.
• The Multiapps Controller (HostValidator.java) rejects underscores during MTA deployments.

The problem manifests at the TLS layer: OpenSSL's wildcard_match() in crypto/x509/v3_utl.c restricts the characters a wildcard (*) can match to [A-Za-z0-9-]. This means a wildcard certificate with a SAN of *.cfapps.example.com will not match my_app.cfapps.example.com in strict TLS implementations. While some TLS libraries (e.g., certain OpenSSL versions used by curl) are lenient and accept underscores, others (Go's crypto/tls, recent urllib3, Java JSSE) reject them. This inconsistency makes the issue difficult to diagnose — routes appear to work for some clients but fail for others.

Steps to Reproduce

1. Target a Cloud Foundry environment:

   cf target -o my-org -s my-space
   

2. Create a route with an underscore in the hostname:

   cf create-route example.com --hostname my_app
   

3. Map the route to an application and attempt to access it via a TLS client with strict hostname verification (e.g., a Go application, or Python with recent urllib3).

Expected Result

The Cloud Controller should return a warning in the API response indicating that the hostname contains characters not valid in DNS hostnames per RFC 952/1123, and that this may cause TLS hostname verification failures with certain clients.

The route should still be created (to avoid breaking existing workflows), but the warning should make the user aware of the potential issue.

Current Result

The route is created without any warning. The hostname passes validation because the regex [\w-] includes underscores. The user has no indication that the route may cause TLS issues until a client with strict hostname verification fails to connect.

Possible Fix

Add a validation warning (not an error) when a hostname contains underscores. This could be implemented as:

1. API-level warning: Return the route creation response with a warnings field (Cloud Controller V3 already supports response warnings) when the hostname matches /_.*/. The warning message could read:

   Hostname contains underscore(s), which are not valid in DNS hostnames per RFC 952/1123. This may cause TLS certificate verification failures with some clients. Consider using hyphens instead.

2. Validation change: In app/messages/route_create_message.rb, add a custom validator that checks for underscores and populates a warning (rather than an error) on the response. The existing regex and error path should remain unchanged to avoid breaking existing automation.

The relevant files to modify are:

• app/messages/route_create_message.rb (line 28) — API message validation
• app/models/runtime/route.rb (line 118) — model-level validation
• app/actions/route_create.rb — route creation action (where the warning can be added to the response)

Relates to #859

Start with the hostname validation in app/messages/route_create_message.rb and app/models/runtime/route.rb, then trace app/actions/route_create.rb and the Cloud Controller V3 response warning handling. Confirm how warnings are attached without turning validation into an error. Done means route creation still succeeds for underscores while the API response clearly warns about DNS and TLS compatibility.