Earlier today, I talked with my ex-colleague about things being bloated and unnecessarily complicated in software. Here we have a perfect example. $ curl -v

Earlier today, I talked with my ex-colleague about things being bloated and unnecessarily complicated in software. Here we have a perfect example. $ curl -v icanhazip.com > GET / HTTP/1.1 > Host: icanhazip.com > User-Agent: curl/8.2.1 > Accept: */* curl is being curl here: protocol, host, shortest possible user-agent string, nothing extra. Let's see the reply: < HTTP/1.1 200 OK Okay. < Date: Tue, 01 Aug 2023 06:59:21 GMT I am not sure, is it really necessary? I will use NTP if I need to know the current GMT. RFC doesn't state this header as mandatory. < Content-Type: text/plain < Content-Length: 14 Okay, nice to know. < Connection: keep-alive Really? What's a use case here? Do I need to be reminded of my IP again in a few seconds? Or is it in case my IP will quickly change? Oh, never mind... < Access-Control-Allow-Origin: * < Access-Control-Allow-Methods: GET Now, this is a bit ridiculous. Why would the fetch-based browser app rely on a third-party service to determine the client's IP? < Set-Cookie: [250 bytes of total abomination] Why, oh why? Why do I need to receive this and keep it somewhere? All I want is to haz IP! Can I only haz IP? < Server: cloudflare Okay, a little vanity never killed nobody. < CF-RAY: 7efc32adfef5c21e-VIE I know what Cloudflare Ray is. The question is: why do I need it here? < alt-svc: h3=":443"; ma=86400 Good to know, maybe, but to be honest - this is redundant too. xxx.xx.xx.xx [my IP address, masked for privacy reasons] At last! Now I can do my thing with the IP I just haz. I will not rant here about extra bytes transferred, extra bandwidth congested, extra electricity burned, and so on. Sapienti sat. Two side notes: it replies with HTTP 1.1 on HTTP 1.0 request, and it still puts alt-svc header into https reply. I rest my case.