5 ms·

HTTP/1 simplicity comes not from text nature, but from it's clear concept and limited functionality. At core, it's just request-reply + key-value metadata. Whe

by saba2008 5y ago

HTTP/1 simplicity comes not from text nature, but from it's clear concept and limited functionality. At core, it's just request-reply + key-value metadata. Whenever it's text, or binary, it does not matter much. But writing HTTP/2 frame types in letters would not make them any easier to understand.

ahartmetz 5y ago
There are also keep-alive, caching (a big topic), chunked transfer encoding, header parsing peculiarities, and authentication in HTTP. The combination of these creates some nice opportunities for implementation bugs. Source: have worked on a client-side implementation. Now, HTTP/2 isn't even conceptually simple, I agree about that... it seems ugly.
- tokamak-teapot 5y ago
  One good thing is that you don’t have to support everything if you’re writing a server. It just depends on what kind of use cases you want to support.
- jbverschoor 5y ago
  That came with http/1.1 ;-)
- merb 5y ago
  > implementation bugs. Source: have worked on a client-side implementation well because the hard part is the client-side. caching is a client-side only thing with http, keep-alive is a thing that a server pushes to a client, the same with chunked transfer, which is not as easy to implement for a client like it was with content length. basically a server does only need to implement certain headers, but a client needs to know all. also most clients even accept bad servers, like content for head requests, etc.. most stateless protocols put a lot of burden into clients. h2 on the other hand is stateful and keeps the same hard semantics onto the client side and also makes servers more complex, because it's a state machine.
secondcoming 5y ago
HTTP allows a TimedOut response to be sent by a server to request you haven't yet sent. So it's not strictly request/reply.
- saba2008 5y ago
  '100 Continue' would probably be better example of breaking request/reply flow, as it provides useful functionality and requires non-trivial implementation and compatibility measures. While '408 Request Timeout' is somewhat dubious fig leaf over TCP RST

ahartmetz 5y ago

There are also keep-alive, caching (a big topic), chunked transfer encoding, header parsing peculiarities, and authentication in HTTP. The combination of these creates some nice opportunities for implementation bugs. Source: have worked on a client-side implementation. Now, HTTP/2 isn't even conceptually simple, I agree about that... it seems ugly.

tokamak-teapot 5y ago
One good thing is that you don’t have to support everything if you’re writing a server. It just depends on what kind of use cases you want to support.
jbverschoor 5y ago
That came with http/1.1 ;-)
merb 5y ago
> implementation bugs. Source: have worked on a client-side implementation well because the hard part is the client-side. caching is a client-side only thing with http, keep-alive is a thing that a server pushes to a client, the same with chunked transfer, which is not as easy to implement for a client like it was with content length. basically a server does only need to implement certain headers, but a client needs to know all. also most clients even accept bad servers, like content for head requests, etc.. most stateless protocols put a lot of burden into clients. h2 on the other hand is stateful and keeps the same hard semantics onto the client side and also makes servers more complex, because it's a state machine.

secondcoming 5y ago

HTTP allows a TimedOut response to be sent by a server to request you haven't yet sent. So it's not strictly request/reply.

saba2008 5y ago
'100 Continue' would probably be better example of breaking request/reply flow, as it provides useful functionality and requires non-trivial implementation and compatibility measures. While '408 Request Timeout' is somewhat dubious fig leaf over TCP RST