In #HTTP land, this paper has surfaced and is being discussed:

"HTTP Conformance vs. Middleboxes: Identifying Where the Rules Actually Break Down"

Document:

https://repository.kaust.edu.sa/server/api/core/bitstreams/4a5eda74-03c5-4b77-87a9-2001e78b7b66/content

Curiously old versions of most components were used as basis. Also relevant is @mnot's comments on the httpbis list:

https://lists.w3.org/Archives/Public/ietf-http-wg/2025JanMar/0227.html

Ok - I've been told that HTTP 418 belongs in the 400 block because it's the same as requesting a non-existent file. This argument claims that 418 is the same as 404.

I tend to think of 418 as being more analogous to 501. You cannot put coffee in a teapot, which is a statement about the teapot.

#ImportantThoughts #Protocols #HTTP

Problem with that is (besides occasional bugfixes), most people including myself would see #curl to be functionally complete and anything "nice to have" would be considered not worth the balooning in #complexity and #size.

• I mean, does curl need to be able to do #BitTorrent (magnet:), #IPFS (ipfs://) or god forbid #blockchain (i.e. #EVM) support?
• Do you really want to integrate @torproject / #Tor support natively into curl when using #HTTP (localhost:8118) and #SOCKS5 (localhost:9050) #proxy allows for the same and doesn't necessitate having to handle and ingest Tor arguments as well??

In fact if #toybox didn't have a #wget implementation that I could use for OS/1337 I would've merely chosen tiny-curl -o as a global alias or if #tinycurl wasn't an option, curl -o instead.

• Maybe someone who wants to have said functionality like tor support built-in will go and IDK make i.e. #[url=https://infosec.space/tags/neocurl]neocurl[/url] or sth. along those lines or build something like #[url=https://infosec.space/tags/ethcurl]ethcurl[/url] or #[url=https://infosec.space/tags/tor]tor[/url]curlor #[url=https://infosec.space/tags/ipfs]ipfs[/url]curl or whatever...

That being said I am glad curl isn't solely maintained by you but has other contributors (give them a shoutout!) but I also am glad you maintain that vital software that most "#TechIlliterate #Normies" most likely never heard of but propably use on a daily basis as part of all the #tech they use to #consume media with...

• I consider curl to be "the #vim of downloaders" (tho that's kinda insulting and limiting since curl is more than just a downloader and more intuitive than vim) with wget being "the #vi of downloaders" (tho wget is even simpler to use than vi)...

Either way, curl is awesome...

#OS1337 #Enshittification #Bloat #Bloatware

Set aliases globally for all users

I have certain paths, which are too long to type, so I need to wrap all those in one script as alias and source that script to my existing package code. These should set alias permanently over that

^{Stack Overflow}

I have an early prototype of #w3m using #libcurl. This means today is the day when #w3m did its first HTTP/1.1 request.

Only 28 years after HTTP/1.0 was obsoleted.

I'm excited!

#http

The 2024 #HTTP Workshop, day two

https://daniel.haxx.se/blog/2024/11/13/the-2024-workshop-day-two/

The 2024 Workshop, day two

The fun continues. See day one. In an office building close to the Waterloo station in London, around 40 persons again sat down at this giant table forming a big square that made it possible for us all to see each other.

^{daniel.haxx.se}

"Incremental #HTTP Messages" proposal:

Upon receiving a header section that includes the Incremental header field, HTTP intermediaries SHOULD NOT buffer the entire message before forwarding it. Instead, intermediaries SHOULD transmit the header section downstream and continuously forward the bytes of the message body as they arrive.

https://datatracker.ietf.org/doc/draft-kazuho-httpbis-incremental-http/