hobohacker

This comes up periodically on chromium-dev. I've answered it here: https://groups.google.com/a/chromium.org/d/msg/chromium-dev/....

In short, we don't want to support other consumers, sorry. Feel free to do code drops, they should work fine.

I think the source of the confusion is that you are conflating sharing of a [SPDY] connection with sharing of a resource identifier (a URI/URL). This is a misunderstanding. SPDY multiplexes multiple streams over a single connection (or more accurately, a session). Each stream is used in the HTTP layering case to correspond to a request/response pair for fetching a resource at a URL. So, even though a single connection is shared, different resources at different URLs can be simultaneously requested over the same SPDY connection.

In short, SPDY does not imply combining resources. Application level combining of resources is a common hack to work around lack of parallelization at the HTTP/1 protocol level, but as noted, it has deficiencies.

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.

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

While intriguing, this suggestion has a number of issues. For one, it implies coalescing a number of resources into a single resource named by a single URL. This means that all resources would have to share the same caching properties. Since it's generally desirable to keep the main document (the HTML) uncacheable to allow site updates, this would imply eliminating the vast majority of web caching, which sounds undesirable.

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.