Fix populate a malformed remote ip / host header value by remote ip valve (filter)

[Chenjp]

Remote ip valve / filter may populate a malformed header value into request attribute without basic validation, those unexpected remote ip/host values may mislead downstream components.

Per de-facto standards, ignore malformed xff header rather than Raise 400.

[markt-asf]

If the remote IP valve/filter is being used, then the data is being provided from a trusted source and can assume to be valid.

If validation were to be added then it would be a "defence in depth" measure.

Adding validation slows down every request. Yes, invalid data may cause problems but I am not convinced the risk of that (given that the source data should be correct) justifies the per request cost of validation. Maybe making validation optional is a way forward.

The proposed validation is insufficient and allows more characters than are permitted in IP addresses.

Validation by character is insufficient. It will not prevent an IP address like "999.999.999.999". If validation is going to be applied then it needs to be complete. There is code that might help in HttpParser (although it can't be used as-is unless it is decided that host names are acceptable in the header).

Given that the remote IP valve/filter is providing security related functionality (the new remote IP will be used to make security decisions and/or generate security logs) then I'm not sure, if the data is going to be validated, that ignoring invalid data is correct. Rejection with a 400 seems more appropriate.

[Chenjp]

Potential issues:

• remote ip / host may be manipulated if xff misconfiguration in trusted intermediate layer / proxy
• security logs message injection

We may declare it is not tomcat fault: The trusted proxy service violates the implicit trust assumptions of the Tomcat.

Or we can do more to make it safer, and audit trail trustworthy:

1. Escaping those fields in XxxAccessLogValve: prevent the ip/host field from being a window to poison the entire log entry (overflow to other critical audit fields, e.g., uri, status)
2. Remote Ip Valve / filter: as security related components, need ignore apparent invalid headers which were malicious obviously, or
3. Performing syntax / semantics checking in HttpParser, reject with 400.

[Chenjp]

2026-04-18 00:00:00 999.999.999.999 GET /sansitive-ops 200

# crafted header jumping to URI / status fields.
2026-04-18 00:00:00 Crafted-Proxy GET /noop.html 403 GET /sansitive-ops 200

{..., "host":"999.999.999.999"}{"status":"403", "uri":"/sansitive-ops","status":"200",...}

Crafted header may result in a systemic failure of audit integrity.