← Back to context

Comment by Cthulhu_

13 hours ago

If you do have tests relying on it... stop it:

> This is not a service; avoid relying on it for testing and monitoring purposes.

21 comments

Cthulhu_

Reply
zahlman  4 hours ago

Before this submission, it genuinely never occurred to me that people would actually have tests that rely on example.com being up, let alone depend on its content.

smashed  10 hours ago

Opus 5.5 in Claude code added a unit test checking DNS and internet access using example.com as the target on a project I'm building yesterday. It's an agent sandbox (I know, yet another), so the call was expected to fail, but still... It should have at least targeted a captive portal endpoint or a project owned domain.

I caught it in review but thousands of others won't.

That ship has sailed I would say.

  • nemomarx  9 hours ago

    If it breaks in those thousands of projects, that will be an important lesson to review your agents more carefully. So a net win?

    • vikramkr  7 hours ago

      More likely the agents will fix it as fast as they made it and people will continue not caring so much about reviewing what agents are doing for cases where they don't care so much (which is a lot of cases)

SamuelAdams  11 hours ago

So is wrong to use captive.apple.com for tests as well? It's nice to know your network can reach the internet and these pages are generally fairly reliable.

[1]: https://captive.apple.com/

  • lxgr  6 hours ago

    These pages are unfortunately getting special treatment from quite a few networks these days, among other things to avoid iOS users getting stuck in a loop of trying to connect, and getting disconnected by the OS due to a "non-working connection" for local-only networks like in-flight entertainment systems.

    It's a shame that we don't have any standards for the concerns of canonically testing Internet reachability and for authoritatively redirecting network users to a captive payment portal (without having to resort to ugly hacks that often break with TLS).

  • nemomarx  11 hours ago

    If they say that it's not intended as a reliable service for testing purposes it can't be that reliable, and they might take it down or change the structure arbitrarily at any time, etc.

    So yeah I would pick something simpler for a network access test probably?

  • 98codes  3 hours ago

    Just don't blame the user and/or their internet service when the service you're relying on inevitably goes down.

  • patmorgan23  9 hours ago

    Why not ping 8.8.8.8 or 1.1.1.1 or time.windows.com? Things that are actually designed to be highly available services

    • ceejayoz  9 hours ago

      Is there any reason to believe captive.apple.com is any less "designed to be highly available" than time.windows.com?

      It's a static page that every Apple device relies on saying only:

        <HTML><HEAD><TITLE>Success</TITLE></HEAD><BODY>Success</BODY></HTML>

      2 replies →

    • encom  6 hours ago

      1.1 is enough.

        ~$ ping -c1 1.1
  PING 1.1 (1.0.0.1) 56(84) bytes of data.
  64 bytes from 1.0.0.1: icmp_seq=1 ttl=56 time=7.89 ms
  
  --- 1.1 ping statistics ---
  1 packets transmitted, 1 received, 0% packet loss, time 0ms
  rtt min/avg/max/mdev = 7.888/7.888/7.888/0.000 ms

      3 replies →

bevr1337  5 hours ago

I have been naively using example.com in the browser. WHATWG URL throws if there is no origin when constructing the URL. Web apps that need to construct _just_ the pathname must go through this song and dance. `new URL("/blah", "https://example.com").pathname` This isn't relying on any external example.com service but I'm learning the lesson.