[10.2][remap] Per-request std::string heap allocation in remap host-table lookup

Branch: 10.2.x (10.2.1, commit 31f1f2f3b) · Severity: medium (performance)
Location: src/proxy/http/remap/UrlRewrite.cc:303

What's wrong

URLTable is std::unordered_map<std::string, UrlMappingPathIndex *> with the default std::hash<std::string>, and _tableLookup() calls h_table->find(request_host) with a char*. Every call materializes a temporary std::string from the lowercased host, which heap-allocates/frees for any hostname past the SSO threshold (~15 chars — common for real hostnames). _mappingLookup runs on the request path for every forward remap lookup, so this is an avoidable malloc/free per proxied request.

Fix

Give URLTable a transparent hasher (is_transparent) + std::equal_to<> and look it up with a std::string_view over the already-lowercased host and its known length. PR attached.

Testing

Compiles cleanly on 10.2.x; test_RemapRules passes. clang-format clean.

From an automated multi-lens audit of the 10.2.x branch. Full report on branch claude/codebase-audit-review-9nw7vz (CODEBASE_AUDIT_10.2.md).

Start in src/proxy/http/remap/UrlRewrite.cc at URLTable and _tableLookup(), then inspect the existing remap lookup types and hash usage. Use the already-lowercased host and known length as described, and run test_RemapRules on the 10.2.x branch. Done means the lookup avoids the per-request temporary allocation while the test passes.