Less Dramatic Logs for Netflix Issue

[dnwiebe]

Background: At the time of this writing, the Netflix front end (the JavaScript in the browser) has a bad habit of opening a TCP stream to the Node on port 443 and then immediately closing it again without sending or receiving any data.

This is not particularly harmful, but it does confuse our Proxy Server, because it results in a StreamInfo structure that never gets a hostname (because the hostname comes from the ClientHello TLS packet, and no data means no ClientHello packet means no hostname). Then, when the TCP stream from the Netflix client is shut down, we try to send a last_data = true CORES package to the server to tell it the browser has shut down the stream, but we can't, because we can't find the server, not having a hostname.

Again, this isn't really a problem, because we never initiated the TCP connection to the server (because we don't know what the server is, not having a hostname) in the first place; but the confusion in the Proxy Server causes some ERROR-level logs that could alarm somebody who's tracing through them.

They look like this:

2025-10-29 11:21:34.400 Thd8: ERROR: ProxyServer: No hostname information found in either client packet (Incomplete 0-byte TLS packet) or ProxyServer for protocol TLS, with StreamKey DrFPYfSDJL6w76a+OspnSZJn3HM
2025-10-29 11:21:34.404 Thd8: ERROR: ProxyServer: Couldn't create ClientRequestPayload

Task: Change the way the ProxyServer handles these messages (it's complicated) so that if this happens when the message's last_data flag is true and the message's payload length is 0, the logs are of INFO or DEBUG level rather than ERROR or WARN, so that they don't attract as much attention. We still want to know when Netflix (or some other client that does the same sort of thing) confuses us, but we don't want to be alarmed about it.

[czarte]

I think we could fix this way also those logs:

ERROR: ProxyServer: No hostname information found in either client packet (19-byte ApplicationData) or ProxyServer for protocol TLS, with StreamKey voUdJ4OuQkRP6kGwXoJdrhQ1Zbk

those are most probably the FIN packets also there are 24-byte data sizes, which are most probably Ready to shutdown messages

[dnwiebe]

I think we could fix this way also those logs:

ERROR: ProxyServer: No hostname information found in either client packet (19-byte ApplicationData) or ProxyServer for protocol TLS, with StreamKey voUdJ4OuQkRP6kGwXoJdrhQ1Zbk

those are most probably the FIN packets also there are 24-byte data sizes, which are most probably Ready to shutdown messages

Here's what seems to produce these messages.

1. Server shuts down the TCP stream to the exit Node.
2. Exit Node sends zero-byte last_data = true CORES package to originating Node.
3. Originating Node closes its TCP stream to the browser, sending a TCP FIN frame, retires the StreamKey (no need to wait in this case, because the server terminated the connection and obviously won't be sending any straggler packages), and kills the StreamReader and StreamWriter for that stream.
4. But the browser isn't done. It has been sent the FIN frame, but it has more to say, so it sends more data (in these cases, since it's a TLS connection, they're ApplicationData packets), which stimulates the Node to create another StreamKey (actually, the same one, since it's hashed from IP address, port number, and salt) and set up another StreamInfo.
5. This StreamInfo, of course, will never get a hostname, because it can't extract one from an ApplicationData; so it can't send the ApplicationData to the server, which is where this error comes from. It probably also will never get any more client data, since the browser has received a TCP FIN frame and will soon be sending a FIN frame of its own. It may hang around in the map forever, orphaned and useless and just taking up space, or some mechanism I'm not thinking of may eventually remove it.

If this sequence could be broken somehow (don't restart the connection if you get more client data after sending a FIN, say), then we wouldn't get these messages and it wouldn't be a problem.

Also, this is a different problem with a different solution and should probably be on a different card.