4 ms·

As I regard HTTP to be one of the main hindrance in todays IT industry I feel it is my duty to add my voice to those trying to warn against the now decade long

by rixed 8y ago

As I regard HTTP to be one of the main hindrance in todays IT industry I feel it is my duty to add my voice to those trying to warn against the now decade long trend to wrap everything into HTTP. Things that HTTP makes more complicated: 1. It's a verbose protocol with more often than not a really bad ratio payload over metadata; 2. Client authentication is hard; 3. Server authentication is expensive; 4. It's bad at streaming; 5. It does not help a bit for RPC (no support for fan-out, quotas, fail-overs, retries, ...). Building an infrastructure on HTTP makes it so unreliable that I came to consider one of the reason for Google technical superiority is that they early ditched HTTP completely out and used stubby for everything instead. Maybe they themselves view it as their secret sauce, which would explain why they've never published a comparative review (that I'm aware of)? Many people I've spoken to about this have expressed surprise that there is no HTTP flowing on Google's veins. To many, removing HTTP is like removing the solid ground; but to a former googler, loosing access to stubby and having to work with HTTP again is a painful experience that requires quite some time to accept.

ori_b 8y ago
> they early ditched HTTP completely out and used stubby for everything instead. Yes, when I worked there, it was interesting to realize that they take HTTP, and immediately convert it to protobuf.
icebraining 8y ago
So Google made gRPC (which uses HTTP) just to sabotage their competition? Man, that's devious. By the way, server (and client, if needed) auth is implemented by the TLS layer. Do you propose using something else to secure other protocols?
- rixed 8y ago
  They definitively pushed HTTP2 to help their clients move away from HTTP. My guess is they cannot make stubby public without disclosing too much valuable advantage and probably also knowing that this can only effectively run on their own DC at that point. At least, gRPC is easy to unwrap from HTTP (which is likely the very first step of processing on their side). Regarding protobuf, I'm not a big fan but at least that's not JSON (another awful tech that the industry is taking for granted). Also: TLS is slow, and last time I asked for the best practice to do client auth on HTTPS the general consensus seamed to be "don't do it".
einrealist 8y ago
I don't get it. Why is HTTP such a bad thing? It proved itself worthy many times. Does it cover all of your requirements? Maybe not. Does it prevent you from using something different? No. It is just a protocol for stateless server-client communication. Nothing more. What you build on top of it, is your choice. And you don't have to use it. But it is a mature protocol and it is well understood and it has a huge ecosystem of technology around it, that is just good enough for many use cases. > 1. It's a verbose protocol with more often than not a really bad ratio payload over metadata; Its a stateless protocol. You have to provide all the required meta data (Headers) in a conversation. Otherwise, it would not be able to be stateless. And yes, it does use text, because it would be extremely difficult to create a evolving protocol just by using some more memory-efficient binary tricks. Text is just better for comprehensible semantics. And that's even a good thing in pure machine-to-machine interaction. There is also HTTP/2 which addresses efficiency and latency issues. But it trades that for simplicity of the transport method. > 2. Client authentication is hard; It depends. It can be as easy as sending an Authorization header. Or you can defer authentication to the transport layer (client certificates over TLS). Otherwise, I'd say: Best security is hard. And it won't get easier in other stateless protocols. > 3. Server authentication is expensive; That's just too generic. What does "expensive" mean? For what use case is it too expensive? > 4. It's bad at streaming; It depends what you mean with streaming. I think, you mean legacy binary streams? Yes, HTTP is not meant for that. But you can use HTTP for initiating your custom streaming use case. There is the "Upgrade" header. Or you just provide an URL to your streaming endpoint that uses something different than HTTP or even TCP, as long as the client can handle this stuff (e.g. RTMP). Then there is something that is often misconceived as a utility for streaming: using chunked streams or using the Range header. Chunked streaming is just for fetching content of arbitrary size. And having a server support "Range" allows for fail-over / retries. Its not meant to support continuous streams of data. > 5. It does not help a bit for RPC (no support for fan-out, quotas, fail-overs, retries, ...). You can do RPC if you design your payload around it. See SOAP or even something like RMI over HTTP. Fan-out, quotas, fail-overs and retries. Everything can be done using HTTP. Does the specification itself solve those issues? No and it should not, because it would make it too complex and harm adaptation of HTTP.
bullen 8y ago
I think you are wrong on all accounts, but specifically take a look at Transfer-Encoding: chunked and learn some crypto. Also you don't need to put all those headers in the requests/responses. And soon you will be able to override the horrible User-Agent one even in Chrome.

by rixed 8y ago

ori_b 8y ago

> they early ditched HTTP completely out and used stubby for everything instead. Yes, when I worked there, it was interesting to realize that they take HTTP, and immediately convert it to protobuf.

icebraining 8y ago

So Google made gRPC (which uses HTTP) just to sabotage their competition? Man, that's devious. By the way, server (and client, if needed) auth is implemented by the TLS layer. Do you propose using something else to secure other protocols?

rixed 8y ago
They definitively pushed HTTP2 to help their clients move away from HTTP. My guess is they cannot make stubby public without disclosing too much valuable advantage and probably also knowing that this can only effectively run on their own DC at that point. At least, gRPC is easy to unwrap from HTTP (which is likely the very first step of processing on their side). Regarding protobuf, I'm not a big fan but at least that's not JSON (another awful tech that the industry is taking for granted). Also: TLS is slow, and last time I asked for the best practice to do client auth on HTTPS the general consensus seamed to be "don't do it".

einrealist 8y ago

I don't get it. Why is HTTP such a bad thing? It proved itself worthy many times. Does it cover all of your requirements? Maybe not. Does it prevent you from using something different? No. It is just a protocol for stateless server-client communication. Nothing more. What you build on top of it, is your choice. And you don't have to use it. But it is a mature protocol and it is well understood and it has a huge ecosystem of technology around it, that is just good enough for many use cases. > 1. It's a verbose protocol with more often than not a really bad ratio payload over metadata; Its a stateless protocol. You have to provide all the required meta data (Headers) in a conversation. Otherwise, it would not be able to be stateless. And yes, it does use text, because it would be extremely difficult to create a evolving protocol just by using some more memory-efficient binary tricks. Text is just better for comprehensible semantics. And that's even a good thing in pure machine-to-machine interaction. There is also HTTP/2 which addresses efficiency and latency issues. But it trades that for simplicity of the transport method. > 2. Client authentication is hard; It depends. It can be as easy as sending an Authorization header. Or you can defer authentication to the transport layer (client certificates over TLS). Otherwise, I'd say: Best security is hard. And it won't get easier in other stateless protocols. > 3. Server authentication is expensive; That's just too generic. What does "expensive" mean? For what use case is it too expensive? > 4. It's bad at streaming; It depends what you mean with streaming. I think, you mean legacy binary streams? Yes, HTTP is not meant for that. But you can use HTTP for initiating your custom streaming use case. There is the "Upgrade" header. Or you just provide an URL to your streaming endpoint that uses something different than HTTP or even TCP, as long as the client can handle this stuff (e.g. RTMP). Then there is something that is often misconceived as a utility for streaming: using chunked streams or using the Range header. Chunked streaming is just for fetching content of arbitrary size. And having a server support "Range" allows for fail-over / retries. Its not meant to support continuous streams of data. > 5. It does not help a bit for RPC (no support for fan-out, quotas, fail-overs, retries, ...). You can do RPC if you design your payload around it. See SOAP or even something like RMI over HTTP. Fan-out, quotas, fail-overs and retries. Everything can be done using HTTP. Does the specification itself solve those issues? No and it should not, because it would make it too complex and harm adaptation of HTTP.

bullen 8y ago

I think you are wrong on all accounts, but specifically take a look at Transfer-Encoding: chunked and learn some crypto. Also you don't need to put all those headers in the requests/responses. And soon you will be able to override the horrible User-Agent one even in Chrome.