HTTP/2 - My thoughts while reading RFC7540

Post date: May 24, 2015 5:57:54 AM

Links: HTTP/2, RFC7540 and HTTP/2 FAQ

This is just a quick thought dump written while reading the HTTP/2 RFC 7540.

• It's nice that they included h2c (cleartext) mode. Because many people got upset about mandatory encryption. Some data can be pre-encrypted or just delivered in bulk and doesn't require encryption at all. So encrypting it would only introduce unnecessary overhead.
• 0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a Hmm, fixed long data structures, I would simply preferred something shorter.
• "a variety of flow-control algorithm", even more complexity.
• "how a receiver decides when to send this frame or the value that it sends, nor does it specify how a sender chooses to send packets. Implementations are able to select any algorithm that suits their needs.". That's easy for optimization when you don't know how stuff is going to behave.
• I don't actually know if I like the proportional weighting, but on the other hand using dependencies to build the tree is better solution. Yet these different methods make implementation more flexible and simultaneously even more complex. I would have personally preferred quite basic and simple prioritization system which would have made the job. But this is more advanced stuff
• "Streams can be prioritized by marking them as dependent on the completion of other streams (Section 5.3.1). Each dependency is assigned a relative weight, a number that is used to determine the relative proportion of available resources that are assigned to streams dependent on the same stream." This offers infinite possibility for optimization as well as failing. Yet explicit priority doesn't guarantee anything, it just works as a hint.
• Really loved this one "Implementations MUST ignore unknown or unsupported values in all extensible protocol elements. Implementations MUST discard frames that have unknown or unsupported types. This means that any of these extension points can be safely used by extensions without prior arrangement or negotiation." I've seen so many extensible protocols which immediately break if you extend those. Which is of course ridiculous.
• Option to add padding? Nice, yes I can see this is required at some times so you can change size of objects being delivered to make passive monitoring harder. Also return to binary protocol feels like a flashback. I've been dealing with too many legacy binary protocols in past. XML or JSON feels so fresh compared to those. But I have to say, that binary protocols are more efficient and therefore preferable in this kind of use case where implementations are going to be widely used.
• "An endpoint that receives a SETTINGS frame with any unknown or unsupported identifier MUST ignore that setting." Perfection again, true extendability is here.
• What? No PONG frames? Only PING ACKs. No more world wide PING PONG.
• The push promise system and refusal to receive pushed data etc also adds incredible amount of new optimization possibilities.
• If just web site optimization wouldn't be hard enough already. Streams with push promise add nearly infinite amount of different optimization strategies even on HTTP/2 level. Of course all this has to relate how web browsers parse and render the page, how the JavaScript interacts with it. Sounds like there are new jobs for website speed optimization because it's getting deeper and deeper stuff. Can you use one strategy for all browsers, should you have optimized strategy for every browser. Others might use different rendering engine than others. What if some pages served by your site use different JavaScript framework than others? This is going to be fun. You can spent working full time months just optimizing a site and then you notice that hey, Firefox changed something, as they most probably will. The full stack view of how web site works is going to be amazingly complex and HTTP/2 is just adding one new important part to it. I guess something like CloudFlare's rocket loader and Google's PageSpeed are needed as middleware because getting stuff right otherwise is just way too hard.
• At this point it's easy to forget that the performance optimizing middleware adds again points where code is being modified by very complex rules and can implement tons of more or less interesting bugs. As well as the original code might not be fully compatible with these optimizations as I've already noticed. Some sites show up as completely 'empty' as soon as CF Rocket Loader is enabled. I know, I'm not JavaScript specialist and the code is probably broken on my side, but all I know is that everything works perfectly as soon as I disable Rocket Loader (even if it isn't probably their fault directly). Maybe machine learning will fix this? There are so many combinations to analyze, but it would automate the process what resources should be pushed when and for which platforms and screen configurations and so on.
• My favorite frame type is GOAWAY.
• Even more questions what kind of window size to utilize, how many parallel streams are optimal. Using too many concurrent streams with similar priority just delays completion of the more important streams if prioritization is done incorrectly.
• I also like the enhance your calm (0xb) error message, no need to send 429 / 420 errors anymore.
• I also liked the fact that response can be sent before request, if the response doesn't require any data from the request.
• Header keys are handled being as case-insensitive, but keys containing uppercase must be treated as malformed. Nice, bit confusing also. Why bother doing case-insensitive comparison (which is slower than case sensitive) if case does not matter?
• Connect method basically allows using any other protocol inside HTTP/2. Is HTTP/2 the new TCP? Host header field is not being used anymore, authority field replaces it for HTTP/2 requests.
• Separating static cookies from volatile cookies into different header fields when compressing, Wow. One way to avoid compression dictionary misses. Again one thing that adds to the vast sea of optimization options.
• Push promises must be cacheable, ok, nice.
• Compression must be disabled when using TLS 1.2.
• Must support GCM nice "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256" as well as P-256 elliptic curve. The TLS 1.2 Cipher suite black list was impressively, err lets say ridiculously long. I guess most of current HTTPS sites wouldn't work if I just go and blacklist all of those in my browser settings. Wouldn't it be easier just to list allowed cipher suites than the massive black list? TLS / SSL is just one huge cipher suite mess. GCM suites are going to replace older suites anyway, so I guess 128 / 256 bit AES/GCM are the way to go. No more DHE / CBC or even worse no FS.
• It's also interesting to see how many new attack vectors like slow loris (and countless other HTTP DoS attacks) this HTTP/2 will implement, I guess pretty many. As soon as HTTP/2 clients will be out there, would it be fun to run crashyourhttp2 site which attempts multiple methods of crashing the client.
• All this sounds so complex that we're going to see a pretty mess before things start really working.
• Challenge? Who's going to write a fully HTTP/2 compliant server alone in a weekend? It would be interesting. Or is the technology just going way too(?) complex.
• Ok, maybe it's well possible after suitable libraries are available. I guess this leads to situation where there are less independent implementations and everyones just using the good known libraries. Pretty much the case with SSL/TLS, SSH and IPsec there aren't just too many implementations to choose from.

Related keywords: HTTP/2 some keywords: client, connection, endpoint, stream, frame, peer, receiver, sender, server, gateway, intermediary, proxy, tunnel, payload, http, https, request, response, implementation, resource, URIs, SSL, TLS, security, semantics, HTTP2, h2, h2c, stream identifier, flags, frame size, error, block, push_promise, continuation, settings, identifier, header compression, fragments, sequences, octets, end headers, stateful, context, decompression, discrete, sequence, interleaved, multiplexing, bidirectional, exchange, characteristics, concurrency, concurrently, unilaterally, endpoint, significant, initiating, open, reserved, local, remote, idle, closed, send, recv, state, rst stream, priority, window update, half-closed, flow-control, flow-controlled, prioritize, establish, settings max concurrent streams, refused stream, protocol error, stream error, scheme, interfere, contention, proxy, algorithm, interact, blocking, capability, advertise, operating, deadlock, bandwidth-delay product, transmission, guarantee, processing, particular, suggestion, dependent, dependencies, dependency, parent stream, exclusive, dependency tree, weighting, state management, extending, extension, extensions, services, scope, padding, defines, identifier, identified, establishment, synchronized, synchronization, communication, comprehension, application, padded, consecutive, frame size error, conveys, configuration, acknowledges, peer, receipt, settings header table size, settings enable push, settings max concurrent streams, settings initial window size, settings max frame size, settings max header list size, settings ack flag, push promise, promised, context, octets, associated, opaque, ping, measure round-trip time, determining, initiated, debug, immediately, precede, get, put, delete, activity, gracefully, maintenance, shut down, standards track, circumstances, no error, retry, cleanly, minimally, similarly, counted, unsynchronized, persistently, unauthorized, safeguards, logged, sensitive, privacy, throttling, indirectly, propagation, flow control error, size increment, window update, end stream, flow control window, indicates, permitted, transmit, buffering, capacity, applicable, exceeds, available, asynchronous, aggressively, initial window size, observers, violation, no error, protocol error, internal error, flow control error, settings timeout, stream closed, frame size error, refused stream, cancel, compression error, connect error, enhance your calm, inadequate security, http 1 1 required, semantics, conditional, range, caching, authentication, syntax, routing, request, response, chunked transfer encoding, trailing, carried, blocks, terminate, 101 switching protocols removed, registry, key-value, listing, case-insensitive, malformed, connection specific, header fields, metadata, keep-alive, transfer-encoding, method, scheme, authority, subcomponent, query, target, copying, absolute, optionally, contributing, allocation, trailing, trailers, reliability mechanisms, silently, bindings, alive, active, cacheable, push promise, rst stream, referencing, connect, proxy, mapping, requirements, considerations, keying material, identifier space, transport-layer, gracefully, certificate, resources, URI, TLS, wildcards, misdirected request 421, TLS 1.2, 1.3, Server Name Indication (SNI), generic, unnecessary, context aware, appropriate, performance, security, renegotiation, long-lived, unusable, confidentiality, credentials, handshake, immediately, implementations ephemeral key exchange sizes, ephemeral finite field Difie-hellman (DHE), ephemeral elliptic curve Diffie-Hellman (ECDHE), DHE key sizes up to 4096 bits, black-listed suites, appendix, deployment, triggering, reaction, attacks, cross-protocol, server authority, determining, capabilities, combination, difficult, attackers, cleartext, intermediary encapsulation, field-content ABNF, cacheability, cache-control, denial of service considerations, commitment, storing, state, strictly, waste of resources, abused, expend, processing time, processor, memory, storage, numbers,empty, legitimate, abuses, excess, implementation, commit, critical, correctness, ensuring, Request field too large, disproportionate, load, inexpensive, secret, recover, secrets, attacker, control, demonstrable, exploit, BREACH, settings, client, fingerprinting, user, opportunity, handling, Application-layer Protocol Negotiation (ALPN), protocol IDs, Hypertext Transfer Protocol version 2, PRI, data, header table size, enable push, max concurrent streams, initial windows size, max frame size, max header list size, idempotent, compression, cookie, fips186, rfc2119, rfc2818, rfc3986, rfc4648, rfc5226, rfc5234, rfc7230, rfc7231, rfc7232, rfc7233, rfc7234, rfc7235, tcp, tls-alpn, tls-ecdhe, tls-ext, tls12, alt-svc, bcp90, breach, html5, rfc3749, rfc,4492, rfc6585, rfc7323, talking, tlsbcp, h2-14. h2-16.