HTTP 2.0: GTFO (General Termination of Future Operations)
http2.github.io
http2.github.io
Let's not taint good, old HTTP in the process please.
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.
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. 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.
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!
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
Is it HTTP 2.0's plan to completely replace "middleware" like SPDY with a full featured protocol?
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.
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.
See ietf@ietf.org for more details: http://www.ietf.org/mail-archive/web/ietf/current/maillist.h...
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)
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.
Or maybe I'm over-reacting. No idea.
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.
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.
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?
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.
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.
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.
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.
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.
http://www.youtube.com/watch?v=DiWEu6f65VEHTTP's simplicity is the reason it's been so successful and proved so flexible. Please don't throw it away.
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).
> 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.