@icing while i agree that #http implementations should interpret standards intelligently and possibly diverge where justified, i do not understand why it was "lame" to point out that the spdy to #http2 "gold plating" process brushed over a lot of feedback and controvercies.
🧵
"The state of the art is no longer in finding more sophisticated ways to build JavaScript or CSS. It's not to build at all. To lean on HTTP/2 and the now universal support for import maps to avoid bundling."
#fefe zu #http2 https://blog.fefe.de/?ts=9bdb4a0e
Außerdem ist HTTP/2 eine Google-Erfindung. Google versucht hier also einen Heldenmythos zu etablieren, in dem sie uns vor dem Monster retten, das sie selbst geschaffen haben. Ohne den Teil zu erwähnen, dass sie das Monster geschaffen haben. Zum Kotzen, diese Tech Bros immer. #http
I might be splitting hairs about the semantics of #HTTP PUT, but there seems to be a slight contradiction in #rfc9110
On one hand, a GET after a PUT should return the exact representation that was set by the PUT.
On the other hand, a PUT "might also cause links to be added between the related resources" which seems to say that the representation might be enriched with extra links.
#TIL that the (in)famous “418 I'm a teapot” status code was never intended for HTTP, but only for Hyper Text Coffee Pot Control Protocol (which aimed to humorously illustrate how HTTP is being abused). So the majority of libraries include this status code by mistake and getting rid of it would be a breaking change… https://www.rfc-editor.org/rfc/rfc9110.html#name-418-unused #HTTP#HTCPCP#HTTP418#RFC2324
I'm very grumpy about #HTTP response status code 429 AKA "Too many requests".
It tells you absolutely nothing except that you've been sending too many requests. Sure, but how many are too many? Trial-and-error only gets you so far, and if things change down the line you're back to square one.
I wish we had a way to ask for throttling limits - or even better - if the server-side would respond slowly instead, until you're back below the limit.
Today I Learned what an HTTP 307 does that's subtly different from other redirect responses and that a NextJS res.redirect() uses it by default.
The 307 redirects to the new URL with the same request method (in my case POST). I was redirecting a form submit to an OAuth authorisation URL. Switching to an HTTP 303 swaps the method to GET and has sorted things out.
Pensée désagréable du jour: le protocole #gemini n'est pas écologique car il n'est pas accessible sur du vieux matériel à cause du TLS forcé. Servir des fichiers textes écrits en gemtext en #http est mieux dans ce cas
> While this push for security is good for protecting modern communication, there is a whole web full of information and services that don't need to be secured and those trying to access them from older vintage computers or even through modern embedded devices are increasingly being left behind.
Whether or not #htmx is a good way to build #web apps; the fact that it's #API is composed of #HTML attrs, #HTTP headers, and #JavaScript#events gives big way-it-should-be vibes.
Anyone know of an #http parsing library or code for classic #macos? After decrypting a #SSL#TCP stream I’d love to shove it into a lib that can parse it all out and let me extract the relevant bits. I found HTTP sample code for OpenTransport but not sure if that’s right path. I may also not be thinking of the problem correctly but having fun experimenting and kinda don’t want to write it from scratch #RetroComputing#macintosh