Earlier quoted context omitted.
Agreed. This spec reads more like a brand new and complex transport protocol than an application one. Is it HTTP 2.0's plan to completely replace "middleware" like SPDY with a full featured protocol?
The complexity is not horrible as far as communications protocols go. Anyone know what working implementations exist currently? Ideally, it'd be nice to see actual real world data showing the benefits over http 1.1.
HTTP 2.0: GTFO (General Termination of Future Operations)
71–80 of 89 posts
Re: HTTP 2.0: GTFO (General Termination of Future Operations)
#72Earlier quoted context omitted.
Let's not pretend that HTTP 1.1 was simple. Text formats break down whenever they need to contain arbitrary (possible non-text) data. You get one of: * complex escaping rules (and assorted inefficiencies) * non-text portions embedded within the text protocol (ever tried to parse HTTP with a Java InputStreamReader? you can't properly switch back to binary mode at the end of the headers...) * variable end-of-content ma…
> Binary protocols usually just specify the length of the data, followed by a binary blob with the data. MUCH simpler! It is possible to have the same simplicity with a textual protocol, it is just that most text protocol designers don't bother with explicit prefixed lengths: For example, see: http://cr.yp.to/proto/netstrings.txt
When people say "text protocol" I think they really mean "something I can type into telnet"; stuff like netstrings and BEEP don't really count.
Re: HTTP 2.0: GTFO (General Termination of Future Operations)
#73Oh dear, how did I miss HTTP 2.0? And why are they trying to reimplement TCP exactly? HTTP's simplicity is the reason it's been so successful and proved so flexible. Please don't throw it away.
Te be fair, they are actually trying to reimplement a subset of SCTP. HTTP over SCTP gets all of the advantages of SPDY (which HTTP2 is based off of) except for the header-compression (which could have been separately implemented). Unfortunately NATs don't handle SCTP so you are left with implementing SCTP over UDP, and NATs also don't handle UDP as well as they do TCP, since UDP is stateless.
> Unfortunately NATs don't handle SCTP
It's more than that; pretty much nothing in the wild handles SCTP, and they wanted to build something that can be gradually transitioned to (it will be a rough transition for sure, but it's still supposed to be HTTP).
Re: HTTP 2.0: GTFO (General Termination of Future Operations)
#74Earlier quoted context omitted.
Agreed. This spec reads more like a brand new and complex transport protocol than an application one. Is it HTTP 2.0's plan to completely replace "middleware" like SPDY with a full featured protocol?
HTTP 2.0 started with the SPDY spec and has been smoothed and refined during the IETF process, so yeah, it is planned to completely replace SPDY.
"Smoothed and refined" by the IETF?
Re: HTTP 2.0: GTFO (General Termination of Future Operations)
#75Earlier quoted context omitted.
GTFO and ENHANCE_YOUR_CALM are symptoms of an unprofessional design process. It's not bad that a core standard be plain and functional, in fact it's a sign that the people designing it did so with the seriousness it deserves. If the http wg actually listened to PHK there would be some hope for it not to end up with the complicated garbage that it is now, but they don't.
Give me humanity and a sense of humor over PC-"professionalism" any day of the week and twice on Sunday.
This kind of "sense of humor" doesn't belong in a formal specification document. Sorry.
Re: HTTP 2.0: GTFO (General Termination of Future Operations)
#76Re: HTTP 2.0: GTFO (General Termination of Future Operations)
#77This play on words is a pretty okay joke.
The person who created that acronym would get many Dogecoins from me.
The person is not hard to find:
https://github.com/http2/http2-spec/pull/358
Re: HTTP 2.0: GTFO (General Termination of Future Operations)
#78Earlier quoted context omitted.
HTTP 2.0 started with the SPDY spec and has been smoothed and refined during the IETF process, so yeah, it is planned to completely replace SPDY.
"Smoothed and refined" by the IETF?
What are you seeking to clarify? Hard to tell if you are inquiring as to how that happened, quibbling with the word choices, or disagreeing completely.
Re: HTTP 2.0: GTFO (General Termination of Future Operations)
#79Earlier quoted context omitted.
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.
I'm sorry, but are you really implying that HTTP doesn't scale?
Are you really implying it doesn’t? So many Web “best practices” are working around the limitations of HTTP and the web 1.0 legacy we still carry around. See:
1. Concatenating resources (1 CSS file is worlds better than 50. Need it be?)
2. Inlining resources (see above)
3. Scaling, yes, is very hard! Look at all the techniques for deploying updates to web apps without breaking users' experiences.
I’m not saying HTTP2.0 will or won't solve all these problems, but clearly there is much room for improvement over HTTP 1
Re: HTTP 2.0: GTFO (General Termination of Future Operations)
#80Earlier quoted context omitted.
It also stands for Great Tanzanian Flying Orangutans and thousands of other things (in the sense that it forms an initialism of those words), but the standard definitely uses General Termination of Future Operations.
That may be so, but I have a very hard time believing that GTFO was not chosen because of its more established meaning.
I have no idea what you're talking about. :-)