Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTTP 2.0: GTFO (General Termination of Future Operations)

http2.github.io

Post reply on HN
Print view View original

61–70 of 89 posts

Re: HTTP 2.0: GTFO (General Termination of Future Operations)

#61

Post by pwg »

ynik wrote: post #56
bitwize wrote: post #10

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

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

Re: HTTP 2.0: GTFO (General Termination of Future Operations)

#62

Post by ubernostrum »

salgernon wrote: post #59
josteink wrote: post #24

Earlier quoted context omitted.

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.

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 wa…

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.

Re: HTTP 2.0: GTFO (General Termination of Future Operations)

#63

Post by aidenn0 »

skywhopper wrote: post #53

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.

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.

Re: HTTP 2.0: GTFO (General Termination of Future Operations)

#64

Post by dragonwriter »

mseebach wrote: post #33
diminoten wrote: post #32

Earlier quoted context omitted.

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.

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.

Re: HTTP 2.0: GTFO (General Termination of Future Operations)

#65

Post by downer82 »

diminoten wrote: post #32
mseebach wrote: post #31

Earlier quoted context omitted.

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…

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.

As a devoted fan of the well-known baseball player Babe Ruth (a man who was known to enjoy an occasional cup of coffee, in coffee serving establishments), I find your presumption of a feminist monopoly on the word "Babe" repugnant and chauvinist.

Re: HTTP 2.0: GTFO (General Termination of Future Operations)

#68

Post by rakoo »

meowface wrote: post #11
RyanZAG wrote: post #7

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?

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)

Re: HTTP 2.0: GTFO (General Termination of Future Operations)

#69

Post by diminoten »

mseebach wrote: post #33
diminoten wrote: post #32

Earlier quoted context omitted.

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.

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 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:

    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.
I'm looking at definition 3a. The context tells me it's probably not 1 or 2, and 3b doesn't make much sense as there is no prior established relationship or context for which a familiar or affectionate tone to take (it's just two words, after all).

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.

Re: HTTP 2.0: GTFO (General Termination of Future Operations)

#70

Post by salgernon »

ubernostrum wrote: post #62
salgernon wrote: post #59

Earlier quoted context omitted.

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 wa…

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!
Post reply on HN