Skip to main content

Week 8 Session: What does it talk to?

Inventory your program's network requirements, then find out which of them a browser can actually satisfy and what the rest would cost

19 April 2027

Inventory first, then sort by what can actually be tested.

The inventory. Every host, every port, every protocol. Does it listen? Does it need UDP? Does it hold a connection open, or is it request-response? Does it care about the exact bytes of its own request?

The HTTP endpoints you can test directly. Issue the request from a browser and see what comes back. The answer is immediate and binary: either the origin sends the header that permits you to read the response, or it does not.

Try a spread — an API that advertises support, a vendor API that does not, a package registry, and something of your own where you control the headers.

Everything else you cannot test that way, and pretending otherwise is the mistake this session exists to prevent. A raw TCP service, a UDP protocol, or anything that listens will not answer a browser request at all. For those the question is not “does it work” but “what shape of answer is available”:

Notice that the first two are the same mechanism. Nothing below HTTP leaves a browser without being tunnelled by something, and the interesting differences are about ownership and abstraction rather than transport.

Each of those costs something — a server you now run, a network you now join, a protocol you now maintain. Price at least one of them.

Bring back: how many of your program’s endpoints are directly reachable, what you would do about the rest, and what that would cost somebody to operate.

The spec

What you bring to the session. Written so a reader can tell whether it has been met without asking you.

Teaching team