Expose SNI / Virtual Hostname in TIdContext for TIdCustomTCPServer #25
Description
The Problem
Modern TaurusTLS) support Server Name Indication (SNI), allowing the IOHandler to select the correct server certificate based on the client's handshake request.
However, TIdCustomTCPServer and its descendants currently lack a mechanism to propagate this requested virtual host name from the IOHandler up to the TIdContext instance. This missing link prevents developers from implementing true logic-based Virtual Hosting within the server events (e.g., OnConnect or OnExecute).
Security Implications
This limitation creates a specific security gap for TIdCustomHTTPServer descendants. While HTTP-based virtual hosting works via the Host header, the application currently cannot verify that the HTTP Host header matches the SNI hostname used during the TLS Handshake. This discrepancy can lead to security vulnerabilities (such as Domain Fronting or Host Header Injection attacks).
Proposed Solution
Add a mechanism (e.g., a TargetHost property) to TIdContext or TIdIOHandler that allows the underlying SSL/TLS transport to expose the SNI hostname requested by the client.