Slashdot Mirror

← Back to Stories (view on slashdot.org)

HTTP 2.0 Will Be a Binary Protocol

Posted by timothy on from the cram-your-stuff-in-this-box dept.

earlzdotnet writes "A working copy of the HTTP 2.0 spec has been released. Unlike previous versions of the HTTP protocol, this version will be a binary format, for better or worse. However, this protocol is also completely optional: 'This document is an alternative to, but does not obsolete the HTTP/1.1 message format or protocol. HTTP's existing semantics remain unchanged.'"

6 of 566 comments (clear)

  1. Re:Binary protocol.. and what else? by gl4ss · · Score: 4, Informative

    It's nice to have a link to the draft. But couldn't we have just a little more "what's new" than it's binary? This is slashdot... Filled with highly techincal people. At least a rundown of the proposed changes would be very helpful in a discussion. The fact that they're proposing a binary protocol doesn't really matter to anyone besides anyone who wants to telnet to a port and read the protocol directly.

    from quick glance, multiple transfers and communications channels("streams" in the drafts lingo) can be put through the single connection, cutting tcp connection negotiations.

    --
    world was created 5 seconds before this post as it is.
  2. Re:Makes sense by Progman3K · · Score: 4, Informative

    Yes, but considering TCP is a core part of IP... what you did kind of falls flat.

    Nope, that's like saying hamburgers are a core part of cows.

    You make hambugers out of cows, you don't make cows out of hamburgers.

    You make TCP out of IP, you don't make IP out of TCP.

    --
    I don't know the meaning of the word 'don't' - J
  3. Re:Makes sense by PhrostyMcByte · · Score: 4, Informative

    It might be bloated and slow. But it is also easily extendable and human readable.

    Human readable yes, extendable no. Well, it's not extendable in any meaningful way. Even though it looks like it on a quick look, if you read the spec you quickly realize there really is no generic structure to a message -- you cannot parse an HTTP request if you do not fully understand it. Even custom headers like the commonly used X-Foo-Whatever are impossible to parse or even simply ignore, so implementations just use an unspecified de-facto parsing and pray to the web gods that it works.

    This makes HTTP parsers very complicated to write correctly and even moreso if you want to build a library for others to extend HTTP with. This isn't a text VS binary issue, but simply a design flaw. Hopefully HTTP 2.0 fixes this.

    As they say, HTTP 1.1 isn't going anywhere -- this'll be a dual-stack web with 2.0 being used by new browsers and 1.1 still available for old browsers/people.

  4. Re:Makes sense by redalien · · Score: 5, Informative

    https://en.wikipedia.org/wiki/CRIME_(security_exploit)

  5. Rationale by hebcal · · Score: 5, Informative

    The rationale for http-2.0 is available in the http-bis charter. Quoting the spec:...

    As part of the HTTP/2.0 work, the following issues are explicitly called out for consideration:

    • * A negotiation mechanism that is capable of not only choosing between HTTP/1.x and HTTP/2.x, but also for bindings of HTTP URLs to other transports (for example).
    • * Header compression (which may encompass header encoding or tokenisation)
    • * Server push (which may encompass pull or other techniques)

    It is expected that HTTP/2.0 will:

    • * Substantially and measurably improve end-user perceived latency in most cases, over HTTP/1.1 using TCP.
    • * Address the "head of line blocking" problem in HTTP.
    • * Not require multiple connections to a server to enable parallelism, thus improving its use of TCP, especially regarding congestion control.
    • * Retain the semantics of HTTP/1.1, leveraging existing documentation (see above), including (but not limited to) HTTP methods, status codes, URIs, and where appropriate, header fields.
    • * Clearly define how HTTP/2.0 interacts with HTTP/1.x, especially in intermediaries (both 2->1 and 1->2).
    • * Clearly identify any new extensibility points and policy for their appropriate use.
  6. Re:Makes sense by Anonymous Coward · · Score: 5, Informative

    No, the parent is right, and this weakness has been demonstrated in recent HTTPS attacks like BEAST and CRIME.

    It works like this. You visit a site that has malicious JavaScript which sends a HTTPS request to some site (like your bank). This request will include whatever known plain-text that the JavaScript wants to send, *plus* any cookies you have stored for the target site, possibly including authentication cookies. If the plain text happens to match part of that authentication cookie, then the compressed headers will be smaller than if they if they don't match. If the attacker can monitor this encrypted traffic and see the sizes of the packets, then they can systematically select the known plaintext to slowly learn the value of the authentication cookie.

    This can be done today in about half an hour. And the attack setup is feasible - consider a public WiFi access point that requires you to keep a frame open in order to use their WiFi. This gives them both the MITM and JavaScript access needed to perform this attack.

    Sorry for posting as AC - slashdot logged me out and I have a meeting in 5 minutes.