Comment by hobohacker | Hacker News Reader

Comment by hobohacker | Hacker News Reader

It's unclear to me what advantages this proposal has over a HTTP/2.0 proposal using HTTP Upgrade. AFAICT, the client is unable to rely on HTTP/1.2 support in the first roundtrip. Therefore, it cannot begin utilizing the new proposed features. Relying on the HTTP/1.2 HTTP-Version within the Request-Line and Status-Line strikes me as less safe than trying to use the Upgrade header to attempt to upgrade to HTTP/2.0, as it seems much more likely for intermediaries to have broken HTTP-Version parsing than broken Upgrade support. In contrast with this proposal, when using the Upgrade header, there is much more freedom to change the wire level representation of the protocol. And if you're going to do HTTPS anyway, using TLS-NPN to negotiate a completely wire level representation (without an additional roundtrip over the TLS handshake roundtrip[s]) likewise enables more freedom to add features.

It seems like the main reason to prefer this proposal is if you do not want to write another parser for HTTP/2.0 and think that new features afforded by a different wire level representation are not worthwhile.

Another thing to note is that this proposal effectively adds on multiplexing without prioritization. Prioritization is fairly important, otherwise the client application has to do application layer throttling in order to reduce contention. Adding prioritization would help obviate the need to make the link utilization vs contention tradeoff.

You could easily modify this proposal to use the Upgrade header for greater safety in interacting with older systems or use TLS-NPN.

Can you give an example of prioritization in practice?

I see, so your main point really is that you don't think the new features proposed in HTTP/2.0 are worth the change in wire representation.

Prioritization: Generally speaking, documents (HTML) > script/stylesheets (JS&CSS) > subresources (e.g. images). https://insouciant.org/tech/resource-prioritization-in-chrom... https://insouciant.org/tech/throttling-subresources-before-f...

I'm mostly disappointed to see a protocol that has thrived as textual (as have so many others over the years) get a binary layer added.

Some binary layers are helpful: TLS, for example, adds a nice generic encryption layer to connections. SPDY, on the other hand, has intimate knowledge of the operation of HTTP (which it needs to do header compression, for example). For example, the header compression dictionary is based on today's usage of HTTP with no provision for it to change over time.

It is a shame that features that are important to HTTP (multiplexing and priority) are not being added within HTTP itself.

I believe Patrick already well explained why this the binary representation is useful, so I won't bother addressing that.

I'd like to comment on your statement on the header compression dictionary. Firstly, your statement is only true for the initial header compression dictionary. Most of the improvement is achieved strictly through the use of compression at all, with very marginal gains from different compression algorithms or better initial dictionaries. If your implication is that intimate knowledge of HTTP is required for SPDY compression to work well, that is false. Please note the research at http://www.eecis.udel.edu/~amer/PEL/poc/pdf/SPDY-Fan.pdf with the following conclusion: "This result suggests that zlib’s adaptive dictionary evolves to roughly an equivalent state after compressing the first header regardless of the content of the initial dictionary."

Can you clarify what you mean about features not being added within HTTP itself? Where are you drawing the line for "HTTP itself"? I'm curious, since the ideas behind SPDY have already been proposed for HTTP/2.0, and indeed the starting point for the HTTP/2.0 proposal used the SPDY draft, so I don't know what it means that important features aren't being added to HTTP itself.

Yes, that gzip result is unsurprising.

When I think of HTTP I think of a text-based protocol not binary. I fully understand that SPDY has essentially been ratified as HTTP 2.0 given that the charter has been updated to be so close to SPDY itself. Thus at some point what I think if as HTTP will need updating to simply include SPDY and what I currently think of HTTP will be moot.

Reply on news.ycombinator.com