11–20 of 89 posts
The complexity difference between HTTP1 and HTTP2 is pretty huge. Not sure if they're even remotely the same protocol anymore.
Is it HTTP 2.0's plan to completely replace "middleware" like SPDY with a full featured protocol?
The complexity difference between HTTP1 and HTTP2 is pretty huge. Not sure if they're even remotely the same protocol anymore.
The old Unix model (simple, do one thing, text formats, etc.) is dead. The world has come to prefer code and protocols which perform well at scale.
"Receivers of a GTFO frame MUST NOT open additional streams on the connection, although a new connection can be established for new streams." Shouldn't that be "a new connection can be established for existing streams"? (Or did I misunderstand something here?)
> The purpose of this frame is to allow an endpoint to gracefully stop accepting new streams (perhaps for a reboot or maintenance), while still finishing processing of previously established streams.
This play on words is a pretty okay joke.
The complexity difference between HTTP1 and HTTP2 is pretty huge. Not sure if they're even remotely the same protocol anymore.
The old Unix model (simple, do one thing, text formats, etc.) is dead. The world has come to prefer code and protocols which perform well at scale.
The complexity difference between HTTP1 and HTTP2 is pretty huge. Not sure if they're even remotely the same protocol anymore.
The old Unix model (simple, do one thing, text formats, etc.) is dead. The world has come to prefer code and protocols which perform well at scale.
The complexity difference between HTTP1 and HTTP2 is pretty huge. Not sure if they're even remotely the same protocol anymore.
The old Unix model (simple, do one thing, text formats, etc.) is dead. The world has come to prefer code and protocols which perform well at scale.
Needs TITS verb now to complete the picture.