New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proxy Protocol Rewrite #1775

mhils opened this Issue Nov 22, 2016 · 0 comments


None yet
1 participant

mhils commented Nov 22, 2016

We had some discussions about the shortcomings of our current protocol layer implementation and I started working on a prototype of an alternative sans-io architecture to potentially replace that at some point. The purpose of this work-in-progress issue is to collect some general thoughts on what we want to achieve. Some of the problems below are immediate consequences of our current architecture, others could in theory also be solved with what we have, but are still listed here to be considered when we work on that anyway.

Problems with the current implementation

  1. Protocols are thread-based, which yields a variety of subtle bugs and race conditions in the test suite in particular.
  2. No separation between IO and data processing, which makes testing and connection management hard.
  3. Poor isolation between layers. (this can be improved, but it is debatable by how much)
  4. Inadequate handling of timeouts. If clients or servers don't disconnect, connections may stay up infinitely.
  5. The socket object is exposed to layers and dynamically wrapped there (e.g. for TLS), which changes the semantics in subtle ways (see e.g. ssl_read_select ).
  6. No support for TLS-over-TLS, which would be required for what the Chromium guys call a "Secure Web Proxy".
  7. No support for server-side greetings (#1774)
  8. No support for changing the request destination when using HTTP2
  9. We're always in upstream or non-upstream mode. (#1821)
  10. The relationship between WebSocketFlows/HTTP Flows is not really clear (we probably just want to display one of them in the console)
  11. No clear strategy determining when to establish an upstream connection. For example, for server replay it is undesirable to establish a connection right away. On the other side, for server-side greetings, connections need to be established immediately (see e.g. #2464)
  12. No support for sending transparent requests to an upstream proxy (see #2813)
  13. No clear strategy determining if we should be as transparent as possible (e.g. mirror cipher suites offered by the client) or if we should be as secure as possible (only offering ciphersuites we deem secure)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment