Search code examples
gohttpkeep-alive

Can I track if requests belong to the same keep-alive connection as previous requests, with Go's net/http?


While writing a web service accessed by web browsers, a co-maintainer suggested that we allow users to choose to log in to one session without using cookies. (Using hidden HTML forms is something else that we've considered but I'm not very keen on the idea. JavaScript is not acceptable.)

Using the Go standard library's HTTP server or perhaps other mechanics, while setting Connection: keep-alive, is it possible to identify which network connection an incoming request originated from?

  • Storing a pointer to http.Request.TLS (a tls.ConnectionState) won't work because its memory could be freed and the address could be reused, making it possible to hijack sessions.
  • I don't see useful values in http.Request.

It's definitely possible to implement this by accepting requests as a plain TCP/TLS/etc connection, store some information, and construct the http.Requests myself; but that seems like quite a pain.


Solution

  • I don't think that the idea behind the question even works, which means that it will also not work with net/http, no matter what features it offers. The rationale for my doubt:

    • A browser opens multiple HTTP/1 connections even with HTTP keep-alive in order to send requests in parallel (HTTP/1 keep-alive can only to multiple requests after the other).
    • A TLS session can span multiple TCP connections, but only if both sides support session resumptions.

    This means you cannot really replace a HTTP session with "same TCP connection" or "same TLS session". Additionally even with HTTP keep-alive an idle TCP connection is closed after a while, loosing the "session".

    All of this is independent from the library or programming language used.

    Thus, use HTTP cookies to keep a session at the HTTP level. That what they were invented for in the first place. All the bad reputation is only because "maintaining a session" can also be misued for tracking users etc. But this is also true with other session mechanisms.