HTTP 2.0: GTFO (General Termination of Future Operations)(http2.github.io)
http2.github.io
HTTP 2.0: GTFO (General Termination of Future Operations)
http://http2.github.io/http2-spec/#GTFO
13 comments
The complexity difference between HTTP1 and HTTP2 is pretty huge. Not sure if they're even remotely the same protocol anymore.
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?
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?
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.
Looks to me that it was an expression of
'quizzical sarcasm' in the form of a question.
I should probably have explained further, but there is a certain amount of irony in that statement.
See [email protected] for more details: http://www.ietf.org/mail-archive/web/ietf/current/maillist.h...
See [email protected] for more details: http://www.ietf.org/mail-archive/web/ietf/current/maillist.h...
The actual current of things is that HTTP 2.0 is what we want in the end, and SPDY is a toy to see what could be cool to add. When something that was tested with SPDY looks right, it is moved to the HTTP2 spec. I think the long-term goal is to deprecate SPDY in favor of HTTP2.
This way of development is very interesting because it enables not only to change rapidly, but also to try completely new things on a different "namespace" (ie without polluting the whole HTTP stacke already deployed)
This way of development is very interesting because it enables not only to change rapidly, but also to try completely new things on a different "namespace" (ie without polluting the whole HTTP stacke already deployed)
Yes, and about time too.
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.
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.
There's a C++ implementation here, but I'm not sure how complete it is: https://github.com/http2d/core
I think nginx and Chrome support SPDY which HTTP 2.0 was based on, so that performance should be able to be tested and be fairly representative of what we can expect.
I think nginx and Chrome support SPDY which HTTP 2.0 was based on, so that performance should be able to be tested and be fairly representative of what we can expect.
But that's the thing...it's _not_ a communication's protocol. It's a transfer protocol...
To-may-to, to-mah-to..
No, because a communication protocol has to handle all the types of problems HTTP and TCP solve. A transfer protocol is concerned with moving data and meta data, not the problems TCP solves.
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.
Since the semantics of 1.1 and 2.0 are the same (besides push) you can choose which encoding you prefer based on your requirements and constraints. In fact, maybe we should rename HTTP/1.1 to "HTTP/2.0 Textual Encoding" or something so that people can feel like they're not missing out on anything. It worked for USB 2.0.
Or we can call SPDY^WHTTP 2.0 "binary barf kitchensink internet multiplex protocol" instead.
Let's not taint good, old HTTP in the process please.
Let's not taint good, old HTTP in the process please.
I've never understood this sentiment. Its not like we can know what is passing through the boxes by watching the blinkenlights - this isn't paper tape anymore.
You have to use tcpdump to break up the binary bits - and since its likely encrypted, set up the appropriate certificates if you want to decipher arbitrary traffic anyway.
If its your own app, you know what requests are going where and can hex dump them any way you choose.
The whole "its binary so its bad" thing is a complete non-issue. I've heard people complaining "netcat doesn't work anymore" but there's no reason why netcat2 can't be used to talk to arbitrary HTTP/2.0 endpoints.
Sorry, I lost some mates in the SOAP wars of the late 90s and I'm still bitter.
You have to use tcpdump to break up the binary bits - and since its likely encrypted, set up the appropriate certificates if you want to decipher arbitrary traffic anyway.
If its your own app, you know what requests are going where and can hex dump them any way you choose.
The whole "its binary so its bad" thing is a complete non-issue. I've heard people complaining "netcat doesn't work anymore" but there's no reason why netcat2 can't be used to talk to arbitrary HTTP/2.0 endpoints.
Sorry, I lost some mates in the SOAP wars of the late 90s and I'm still bitter.
Personally, my issue with HTTP 2 is that it seems to be designed from the assumption that Google-scale is the common or even only use case, and that optimizing Google's bandwidth use is the sole purpose of HTTP.
To me, the real reason is that we want to get to the point where all traffic is secure, and since the cost of establishing that secure connection is high we should do more with the secure connections we've got before letting it drop!
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 markers that cannot occur in the content
Of course, HTTP 1.x uses ALL of the above (see possible values for Transfer-Encoding). It's a horribly complicated mess that is only surpassed by MIME email.
Binary protocols usually just specify the length of the data, followed by a binary blob with the data. MUCH simpler!
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 markers that cannot occur in the content
Of course, HTTP 1.x uses ALL of the above (see possible values for Transfer-Encoding). It's a horribly complicated mess that is only surpassed by MIME email.
Binary protocols usually just specify the length of the data, followed by a binary blob with the data. MUCH simpler!
> 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
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.
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
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
Am I implying that it does? Yes.
1. We do that for other reasons too, anyway, like minifying and optimization. For other things, keepalive has worked fairly well.
2. Sure.
3. This has nothing to do with the protocol.
I don't really disagree vehemently with your points--I'm just pointing out that claiming HTTP doesn't scale is completely ludicrous, given that it literally powers nearly everything of scale.
1. We do that for other reasons too, anyway, like minifying and optimization. For other things, keepalive has worked fairly well.
2. Sure.
3. This has nothing to do with the protocol.
I don't really disagree vehemently with your points--I'm just pointing out that claiming HTTP doesn't scale is completely ludicrous, given that it literally powers nearly everything of scale.
SPDY wouldn't be a thing if HTTP were sufficient at the massive scales we're talking here.
Nonsense. This is the same mentality that prefers EJBs and other complexity for its own sake.
At scale .. Wait - You're trolling, right? Nice try - Almost fell for it.
Pulling up the drawbridge.
http://www.cnnturk.com/bilim-teknoloji/internet/kabul-edilen... now secure connection is must
Needs TITS verb now to complete the picture.
(For those missing the reference, "tits or gtfo" is an internet meme.)
[deleted]
You code in Ruby don't you.
Thanks for that, now I don't know which of you two are trying to be more intentionally offensive.
what does GTFO stand for?
get the fk out!
No, it stands for "General Termination of Future Operations."
no, its both :P
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.
This play on words is a pretty okay joke.
I'm cringing currently. It seems funny now, but in ten years, it'll be as funny as a Java class file's header being 0xCAFEBABE is.
I'd much rather have a joke that doesn't age well than a completely wit-less corporate committee specification.
0xCAFEBABE isn't laugh-out-loud funny (not sure it ever was), but I find it a comforting reminder that Java was actually written by humans. The "Duke" mascot, too. It's not at all hard to imagine an underemployed middle manager learning about it and demanding it being changed, in fear that the Important and Serious people who would write Important and Serious software in Java would think it's not an Important and Serious language.
0xCAFEBABE isn't laugh-out-loud funny (not sure it ever was), but I find it a comforting reminder that Java was actually written by humans. The "Duke" mascot, too. It's not at all hard to imagine an underemployed middle manager learning about it and demanding it being changed, in fear that the Important and Serious people who would write Important and Serious software in Java would think it's not an Important and Serious language.
0xCAFEBABE is (I can't believe I'm going to do this) vaguely sexist though, so the cringe for me, at least, is thinking about my daughter reading that and thinking her father came up with it, and thus believing "BABE" is the kind of phrase dad would use to describe women in general.
Or maybe I'm over-reacting. No idea.
Or maybe I'm over-reacting. No idea.
Yes, you're overreacting. Babe is an endearing term. It's sexist only in the sense that it identifies the gender of the subject of endearment.
> Babe is an endearing term. It's sexist only in the sense that it identifies the gender of the subject of endearment.
When actually used as a term of endearment, it doesn't; its pretty common in direct address as a term of endearment regardless of gender; in that use its not sexist at all.
When used as a noun in the third-person, rather than a name-substitute in direct address, though, its sexist, but its not a term of endearment, there, either.
CAFEBABE can be equally easily interpreted in either sense, so how it is perceived will largely reflect what the viewer is inclined toward seeing.
When actually used as a term of endearment, it doesn't; its pretty common in direct address as a term of endearment regardless of gender; in that use its not sexist at all.
When used as a noun in the third-person, rather than a name-substitute in direct address, though, its sexist, but its not a term of endearment, there, either.
CAFEBABE can be equally easily interpreted in either sense, so how it is perceived will largely reflect what the viewer is inclined toward seeing.
Babe isn't just an endearing term, though. If used by a loved one to another loved one, as you're suggesting, it certainly is. I would never argue that such usage is sexist.
I would, however, argue that a "cafe babe" isn't endearing, or referring to young humans.
As Random House Kernerman Webster's College Dictionary defines it:
Anyway you're right, it's probably an overreaction, I just don't think we should pretend like we suddenly don't know what the word "babe" means at the first sign of trouble.
I would, however, argue that a "cafe babe" isn't endearing, or referring to young humans.
As Random House Kernerman Webster's College Dictionary defines it:
1. a baby or small child.
2. an inexperienced or naive person.
3. Slang.
a. Sometimes Disparaging and Offensive. a girl or woman.
b. (sometimes cap.) an affectionate or familiar term of address.
Anyway you're right, it's probably an overreaction, I just don't think we should pretend like we suddenly don't know what the word "babe" means at the first sign of trouble.
It also assigns them an infantile quality.
> Babe is an endearing term.
No it’s not. It’s only claimed to be by the users for plausible deniability, which actually makes it extra-bad.
> Yes, you're overreacting.
No, they’re not. But the three people jumping out and screaming „overreacting” and „endearing” probably are panicking.
No it’s not. It’s only claimed to be by the users for plausible deniability, which actually makes it extra-bad.
> Yes, you're overreacting.
No, they’re not. But the three people jumping out and screaming „overreacting” and „endearing” probably are panicking.
My girlfriend calls me babe all the time, and I don't think she is being sexist about it.
I agree that cafe babe is sexist (like 'booth babe'). The word babe itself is completely endearing though - my SO and I call one another that all the time.
Quite a few black people use the term „nigger” between themselves, and I know at least one couple that adopted „asshole” as an affectionate term. Not to mention completely ridiculous yet popular terms like „pumpkin”.
Just because some people adopted the word in some narrow context doesn’t change its meaning outside of it. There’s many behaviors that are common and acceptable towards your significant other and yet completely demeaning when applied to a barista (that doesn’t happen to be your significant other). So, whatever people call each other while watching Star Wars reruns is utterly irrelevant here.
Just because some people adopted the word in some narrow context doesn’t change its meaning outside of it. There’s many behaviors that are common and acceptable towards your significant other and yet completely demeaning when applied to a barista (that doesn’t happen to be your significant other). So, whatever people call each other while watching Star Wars reruns is utterly irrelevant here.
The thing with calling someone "babe" is that it's too... forward? It's something that you call people you already know, so saying "babe" to a stranger is presumptuous. Anything in that category would have the same effect I think: honey, sweetheart.
It's also possible to use it in a belittling way, but I can't think of any synonym for "woman" which couldn't, if you use the right tone of voice. That's just general sexism, and the word "babe" wouldn't be worse than "lady" with the same delivery.
If you're talking about something that's not in those two categories, could you like me to it so I can see what you're talking about?
It's also possible to use it in a belittling way, but I can't think of any synonym for "woman" which couldn't, if you use the right tone of voice. That's just general sexism, and the word "babe" wouldn't be worse than "lady" with the same delivery.
If you're talking about something that's not in those two categories, could you like me to it so I can see what you're talking about?
You could say "good morning" in a demeaning way, if you used a certain tone. It depends on specific culture, but usually there's certain very obvious (I have aspergers, so if I can see them, everyone can) protocols of interaction with people you don't know well. And in most situations you'd use the word "babe" at someone you don't know very well you probably shouldn't speak at all. The one exception that comes to my mind is "you're an actor and that's your line". So, yes, it's quite a bit worse than "miss". "Lady" only in third person, like "that lady just drove an 18 wheeler over my foot!"
But yes, honey and sweetheart would work just as badly. And yes, there's quite a few words that are worse. But "hey, they could do worse!" is no real argument. Sure they could.
But yes, honey and sweetheart would work just as badly. And yes, there's quite a few words that are worse. But "hey, they could do worse!" is no real argument. Sure they could.
As a dude whose girl calls him babe, yes you're overreacting.
Pretty sure you're over-reacting. The term isn't remotely sexist.
Actually CAFE is the sexist part, given how it's the choice of drink for macho herd-rearing cowboys who famously see women as little more than trophies. And really, 0 is obviously a vagina, while x is a symbol for a butthole. 0xCAFE then, is two cowboys gangraping a barmaid. BABE is really the least sexist part of that signature.
Assuming it's sexist is sexist, babe is a gender neutral term of endearment.
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.
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.
> GTFO and ENHANCE_YOUR_CALM are symptoms of an unprofessional design process.
I'd chose "having sense of humour" over "professional" every day.
> it's a sign that the people designing it did so with the seriousness it deserves.
Or it's a sign that the people designing it are too serious, focusing on political correctness and not on doing good engineering. Creativity, care about the product and sense of humour often go together.
I'd chose "having sense of humour" over "professional" every day.
> it's a sign that the people designing it did so with the seriousness it deserves.
Or it's a sign that the people designing it are too serious, focusing on political correctness and not on doing good engineering. Creativity, care about the product and sense of humour often go together.
Give me humanity and a sense of humor over PC-"professionalism" any day of the week and twice on Sunday.
It is ok because it makes sense. Unlike other (stupid) acronym jokes, GTFO describes the purpose very well. It is funny the first time you read and usefull because you can renember/recognice it better than TS.
I feel obliged to create an alternative approach, Transport Indicated Termination of Session.
Every organization would have to say to itself, "Option 1 or option 2"
"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?)
You did misunderstand. Read the next sentence:
> 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.
> 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.
Something about this reminds me of RTP...
I still can't decide whatever it's childish or fking awesome!
It means an engineer (or a number of them) is actually having fun while building this. It's a good sign.
Also noticed further down, the error code ENHANCE_YOUR_CALM
That one is documenting existing practice
http://en.wikipedia.org/wiki/List_of_HTTP_status_codes#420
Bits or GTFO
For people interested in a high-level overview of HTTP 2.0 and why an update to HTTP 1.1 is needed, the chair of the relevant IETF working group gave a talk a couple of weeks ago at linux.conf.au called "HTTP 2.0 And You":
http://www.youtube.com/watch?v=DiWEu6f65VEOh 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.
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).
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).