RFC 2616 is not relevant any more, hasn’t been for many years. It was obsoleted by RFCs 7230–7235 in 2014, which were mostly obsoleted just a few days ago by RF

RFC 2616 is not relevant any more, hasn’t been for many years. It was obsoleted by RFCs 7230–7235 in 2014, which were mostly obsoleted just a few days ago by RFCs 9110–9114. Do not refer to RFC 2616 except as a historical document. On the particular points: > 1. It’s just text. Only partly true. HTTP/1 is a textual protocol so that the raw stream is readable, but HTTP is semantics, not text. (That phrase is the key here.) Case in point, HTTP/2 and HTTP/3, which are binary protocols. In fact, even curl -v is not emitting the raw HTTP text, but a reserialisation of what it has already parsed. Some dislike HTTP/2 and later because they’re no longer textual so that you can’t just read the stream, but I say this concern is highly overrated: even HTTP/1 was complex enough in places that treating it as text tended to blow up in your face; better rather to deal with protocol-aware tools (libraries, debuggers, &c.) so that you can interact with it all semantically rather than in serialised form. I will note that this advice would not hold in all domains: not requiring special tooling is a virtue in general (though it comes at a cost), but HTTP is a place where binary encoding is reasonable because it’s so foundational and common that good support for such binary encodings will be widespread. But at the API level, JSON will often be more convenient than protobuf or similar schemes. So overall I’d say that HTTP is not text, and if, after being aware of HTTP/2 and HTTP/3’s binary encoding (which the author seems to be), one still claimed that HTTP was text, then I’d respond that by that definition just about everything is text. > Or the complicated 451 Unavailable For Legal Reasons? It’s not all that complicated, really. There’s an extra related link relation (blocked-by), but beyond that 451 is just a number that indicates intention. See https://www.rfc-editor.org/rfc/rfc7725.html https://www.rfc-editor.org/rfc/rfc7725.html which defines it all. > 418 I'm a teapot is an actual status code that was added to HTTP in 1998 as an April Fools joke. There’s now a movement to keep this status code in the spec. That movement was around five years ago, and it was very quickly resolved in a way that could be seen as either victory or loss: the process began to reserve it, unused. This was finally completed a few days ago in RFC 9110. > Remember the Robustness Principle, which says servers should “be conservative in what they send and be liberal in what they accept”. In the context, this is a misapplication of Postel’s law. Postel’s law was about handling out-of-spec behaviour by the other end, whereas the immediate context here is not implementing in-spec behaviour. I also have to note that Postel was wrong, and his so-called robustness principle tends to actually lead to a lack of robustness, and security vulnerabilities. See https://datatracker.ietf.org/doc/html/draft-iab-protocol-maintenance https://datatracker.ietf.org/doc/html/draft-iab-protocol-mai... (including the delightful name the draft was first given when it was a personal submission: “postel-was-wrong”). —⁂— The title of the article is outrageous clickbait and the author should be ashamed of that fact (since it was clearly done deliberately), but I did discover one thing that I didn’t know about: the Clear-Site-Data response header <https://w3c.github.io/webappsec-clear-site-data/ https://w3c.github.io/webappsec-clear-site-data/>.