Comment by SergeAx

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.