HTTP 2.0: GTFO (General Termination of Future Operations)

http://http2.github.io/http2-spec/#GTFO

by ryanf • 12 years ago

192 85 12 years ago

http2.github.io

vsviridov• 12 years ago

Needs TITS verb now to complete the picture.

knieveltech• 12 years ago

You code in Ruby don't you.

Karunamon3• 12 years ago

Thanks for that, now I don't know which of you two are trying to be more intentionally offensive.

awi34umao5• 12 years ago

(For those missing the reference, "tits or gtfo" is an internet meme.)

returnint• 12 years ago

what does GTFO stand for?

kul_• 12 years ago

get the fk out!

kevinchen2• 12 years ago

No, it stands for "General Termination of Future Operations."

sdegutis• 12 years ago

This play on words is a pretty okay joke.

MysticFear• 12 years ago

The person who created that acronym would get many Dogecoins from me.

EdwardDiego2• 12 years ago

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.

mseebach2• 12 years ago

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.

noptic• 12 years ago

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.

lmm• 12 years ago

I feel obliged to create an alternative approach, Transport Indicated Termination of Session.

mattdeboard• 12 years ago

Every organization would have to say to itself, "Option 1 or option 2"

RyanZAG• 12 years ago

The complexity difference between HTTP1 and HTTP2 is pretty huge. Not sure if they're even remotely the same protocol anymore.

bitwize2• 12 years ago

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.

wmf3• 12 years ago

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.

polarix• 12 years ago

Pulling up the drawbridge.

thirsteh2• 12 years ago

I'm sorry, but are you really implying that HTTP doesn't scale?

gaius• 12 years ago

Nonsense. This is the same mentality that prefers EJBs and other complexity for its own sake.

troels• 12 years ago

At scale .. Wait - You're trolling, right? Nice try - Almost fell for it.

ynik• 12 years ago

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!

meowface• 12 years ago

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?

blueskin_• 12 years ago

Yes, and about time too.

rrmm• 12 years ago

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.

thristian2• 12 years ago

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.

rakoo3• 12 years ago

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)

NoCowLevel• 12 years ago

"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?)

Ari_Rahikkala• 12 years ago

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.

userbinator• 12 years ago

Something about this reminds me of RTP...

SaveTheRbtz• 12 years ago

I still can't decide whatever it's childish or fking awesome!

chipaca2• 12 years ago

It means an engineer (or a number of them) is actually having fun while building this. It's a good sign.

kalleboo• 12 years ago

Also noticed further down, the error code ENHANCE_YOUR_CALM

chipaca2• 12 years ago

That one is documenting existing practice http://en.wikipedia.org/wiki/List_of_HTTP_status_codes#420

eduardoejp• 12 years ago

Bits or GTFO

thristian2• 12 years ago

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=DiWEu6f65VE

skywhopper• 12 years ago

Oh 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.

aidenn0• 12 years ago

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.

rakoo3• 12 years ago

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).

pwpwp• 12 years ago

I don't think profanity has a place in network protocols.

Karunamon3• 12 years ago

It's a good thing there's no profanity in this one, huh?

teacup502• 12 years ago

Yeah, nobody knows what 'GTFO' means ...

darkhorn• 12 years ago

http://www.cnnturk.com/bilim-teknoloji/internet/kabul-edilen... now secure connection is must

HTTP 2.0: GTFO (General Termination of Future Operations)

Related Stories