Tame "reading from ORPort" error logs in meek-server

[dcf]

meek-server operators have asked to disable this error message:

reading from ORPort: read tcp 127.0.0.1:YYYY->127.0.0.1:ZZZZ: read: connection reset by peer

It occurs whenever tor closes the TCP connection between meek-server and itself. This happens very frequently when you restart the meek-server process, because it loses its cache of current session-IDs. When clients connect using their formerly valid session-IDs, meek-server treats them as new connections and opens new ORPort connections. The clients push TLS application data over the new connection, which doesn't match what tor expects from a new connection, so it shuts it down. Right after restarting you get a ton of these messages for a while (can be more than 10 per second).

[dcf]

One possible approach: have client indicate in their HTTP requests whether they intend to start a new session with a new session ID. meek-server would drop requests with an unknown session ID that don't have this bit set, and would request the bit to be not set for any existing session ID. That way we would drop the client connection before it gets passed through to tor.

[yawning]

Replying to dcf:

One possible approach: have client indicate in their HTTP requests whether they intend to start a new session with a new session ID. meek-server would drop requests with an unknown session ID that don't have this bit set, and would request the bit to be not set for any existing session ID. That way we would drop the client connection before it gets passed through to tor.

Hm. Won't this break backwards compatibility?

[dcf]

Replying to yawning:

Replying to dcf:

One possible approach: have client indicate in their HTTP requests whether they intend to start a new session with a new session ID. meek-server would drop requests with an unknown session ID that don't have this bit set, and would request the bit to be not set for any existing session ID. That way we would drop the client connection before it gets passed through to tor.

Hm. Won't this break backwards compatibility?

No; we'll fall back to the previous behavior if clients don't send whatever header has the flag in it (treat it as true/false/null). I think we're going to have to add a header with flags for #12857 anyway.