4 ms·
HTTP is serious about backward compatibility, so a client that speaks HTTP/1.1 (or HTTP/1.0 + Host header) can still talk to most servers out there. Similarly,
by kijin 5y ago
HTTP is serious about backward compatibility, so a client that speaks HTTP/1.1 (or HTTP/1.0 + Host header) can still talk to most servers out there.
Similarly, if you write a server that only speaks HTTP/1.1 (or HTTP/1.0 + Host header), you can put it behind a reverse proxy or load balancer that handles higher versions, does connection management, and terminates TLS. It will work perfectly fine, only without some of the latest performance optimizations that you might or might not even need.
- bawolff 5y agoThat seems like a high risk of http desync attacks, if you're only implementing a subset of http/1.1.
- unixhero 5y agoHow would one attack a static page?
- ric2b 5y agoWhy would you even need a reverse proxy for a static page? This isn't about that.
- unixhero 5y agoI see. Thanks!
- bawolff 5y agoWho said anything about static? This webserver supports cgi, which means it supports php, perl, etc. However even if it didn't, js based client-side apps are probably still attackable in the right set of circumstances.
- chippiewill 5y ago> you can put it behind a reverse proxy or load balancer that handles higher versions, does connection management, and terminates TLS This is even standard practice in many production deployments. Typically you want the proxy or load balancer anyway and there's often little benefit (if any) to using HTTP/2 or HTTP/3 over a very low-latency, high reliability local network.