8 ms·

I don't know what makes http important for reverse proxy or docker. I've reveres proxied and dockerized apps that listen on normal TCP port.

• sneak 5y ago
  Reverse proxying non-http protocols and preserving the client ip back to the backing service involves a terrible hack called Proxy Protocol that IIRC haproxy invented to work around the fact that TCP-directly protocols don't normally allow you to carry metadata (like HTTP does in headers). https://www.haproxy.com/blog/haproxy/proxy-protocol/ https://www.haproxy.com/blog/haproxy/proxy-protocol/ It's messy. The tooling around TLS and reverse proxying for HTTP is much more common and easy.
  • Karrot_Kream 5y ago
    Indeed, and it's because TCP is not meant to deal with that sort of proxy-ing and framing. HTTP is specifically an L7 protocol and that makes it a good spot to do things like framing and signalling (through headers and such).
  • toast0 5y ago
    Is proxy protocol really a terrible hack? (Ok the part where it expects the header to be in a single packet and have no other data kind of is, but that usually works out ok) It's a way to pass some meta data at the beginning of the session and you can configure it. Alternatively, if your proxy and origin are on the same ethernet broadcast domain, you could just change the destination ethernet address and resend the packet as-is, or stick it in an IPIP tunnel.
  • progval 5y ago
    > preserving the client ip back to the backing service involves a terrible hack called Proxy Protocol No need for that, there's an IRC extension to indicate the source IP to the backend: https://ircv3.net/specs/extensions/webirc https://ircv3.net/specs/extensions/webirc It's supported by all the major IRCd implementations these days.
    • sneak 5y ago
      Terrible hacky custom extensions like this is precisely why I just want to talk to it via HTTP.
      • progval 5y ago
        How is this more hacky than X-Forwarded-For + X-Forwarded-Host + X-Forwarded-Proto?