More complete comment about issues with proxies in connection phase

The comment for openconnect_get_connect_url (added in
https://gitlab.com/openconnect/openconnect/-/commit/ec6c0caed28ebf4f60984a49ce3122196f9c87fa)
should mention the possibility that a proxy requires the correct hostname at
the TLS layer (via Server Name Indication, SNI) as well at the HTTP layer
(via 'Host' header), in order to correctly forward it to the VPN server.

See https://gitlab.gnome.org/GNOME/NetworkManager-openconnect/-/issues/46
for a case where the 'Host' header was apparently required.

Signed-off-by: Daniel Lenski <dlenski@gmail.com>

diff --git a/openconnect.h b/openconnect.h
index 8dcccc8fc3f8207b0d195c35c263e247cc3aa252..465a86cfee33dd51c2d5de905cdbaa6f9d5271b3 100644 (file)
--- a/openconnect.h
+++ b/openconnect.h
@@ -488,8 +488,10 @@ const char *openconnect_get_dtls_compression(struct openconnect_info *);
  *
  * Later still, Legacy IP addresses got scarce and SNI was invented, and
  * we started to see servers behind proxies that forward a connection
- * based on the SNI in the incoming ClientHello. So returning just the
- * IP address from openconnect_get_hostname() now made things break.
+ * based on the SNI in the incoming ClientHello (TLS layer), or based on
+ * the 'Host' header in the initial connection-phase request (HTTP[S]
+ * layer). So returning just the IP address from openconnect_get_hostname()
+ * now made things break.
  *
  * So... we need to pass *both* the actual hostname *and* the IP address
  * to the connecting openconnect invocation. As well as the port.