HTTP/3: from root to tip

If reads are not repeatable or can't be lost then you really should caching them.

If you can reset your stream, then just start the firehose. Presumably things like a 401 are rare so the waste is minimal.

I could see a use case for this when network IO is prohibitively expensive and needs to be minimized. You're right that there isn't a great solution.

So, for example, ASN.1 defines syntax for expressing schemas (ITU-T x.680 and others in the x.68x series), and also encoding rules (x.690 and others in the x.69x series).

XDR is one standard for both, syntax and encoding.

In HTTP land syntax is used to refer to encoding. In HTTP/1.x, because the protocol is textual and specified in ABNF, syntax can refer to both things equally well. In HTTP/{2,3} this is no longer the case but it doesn't matter, we continue to use "syntax" to refer to the encoding.

https://blog.sessionstack.com/how-javascript-works-deep-dive...

Browsers are almost at the point where they can just talk gRPC to the backend, but gRPC uses HTTP trailers which browsers do not support.

I don't think, from a networking standpoint, that websockets was really necessary. A browser and a web server already have a socket open that they send messages in either direction on. It's just so much of the web was designed around "client asks for something, server sends the result and closes the connection" that some transition period was necessary to distinguish between the two cases. (You didn't necessarily provision your web server for maintaining hundreds of thousands of open connections.) But now that people are used to the idea of connections sticking around in the context of HTTP, it's no big deal to send arbitrary data over that connection.

I think it's very shortsighted to assume people should (or want) to roll their own streaming protocol when Websocket is already a great fit for many applications.

With quic I'm guessing you could have multiple Websocket and http3 streams within one connection and have them not block eachother on packet loss, which is pretty neat.

The Turkish CA is constrained by Mozilla (and so in Firefox, but may not be constrained in your downstream software that wasn't written by Mozilla and just uses their trust lists wholesale) to just Turkish official sites, government, education, that sort of thing. The others are not subject to any notable constraints for a global CA.

If you don't run Firefox or a Free Unix you probably trust a lot more government CAs. For example Microsoft's list includes 35 root CAs from Australia to Uruguay. It's hard to do a cursory up-to-the-minute examination of Apple's status because they provide a summary of information from the certificate itself which will often have been written by some nerd twenty years ago, leading to descriptions like "Government Root Certification Authority" and "CA Root" (those are both real examples from Apple's actual list) which don't tell a reader anything of value.

I don't regard it as useful morally to try to count a company owned by the government as "the government". Consider the film production company Film 4. This is wholly owned by Channel 4, which is in turn wholly owned by the British government. So we could say the British government made "Four weddings and a funeral". OK, delightful English romantic comedy, sure, maybe drives tourism. "Trainspotting". Maybe it's a warning about how dangerous heroin is? "A Field In England" - Um, now we're struggling, I guess it is set in Britain at least. But wait, "The Motorcycle Diaries" is about the early life of Che Guevara, and "12 Years a Slave" is about a guy who was enslaved, in America. No, Film 4 is just a Film Prodution company, it happens to be owned by the British government, but that's even less relevant than which billionaire owns your favourite hockey team.

And protocols are typically stacked cleanly enough that it'd not be a big problem to replace TLS if another standard comes along to replace it.

  [0] https://tools.ietf.org/html/rfc6698

First of all, we have Certificate Transparency. This allows people to notice CA's behaving badly.

Secondly, we need certs to be signed by many different CA's. Note that this is just my idea, and I know of no intentions to standardize this. Currently, rescinding trust in a CA is a difficult and slow process. This is because rescinding a CA breaks a lot of infrastructure. If instead, certs were signed by multiple CA's, we could just drop a CA and most infrastructure should have signatures by other CAs.

Moreover, if I decided I don't trust the Hong Kong Post-office as a CA, I could drop them from my CA store without breaking the web. Perhaps I could even mark it as 'suspicious' and get notified when a cert is only signed by suspicious CAs.

By combing the two things, when a CA is compromised, Certificate Transparency should tell us about that in about a week, after which trust in that CA can be dropped almost immediately.

Just CT isn't enough. Consider what would happen if CT shows Lets-encrypt or DigiCert is compromised. We'd be forced to slowly drop trust, to allow many sites time to migrate away. Without the ability to drop a CA "like it's hot" Certificate transparency is toothless. It defends against CAs acting selfishly because getting caught by CT is bad for a CA. However, CT does not defend against coercion or compromise of CAs by third parties. Those third parties don't care whether the CA gets damaged. Under the current system they can get at least a month of signed certs for whatever domain they want.