Clients, servers, and addresses

Ava opens a shared album on her phone. The photos appear there, but the service holds the album on its own computers. Her application needs to ask for it.

The program asking is a client; the program answering is a server. A browser can be a client, as can a phone application or another service. People also use “server” for the computer running the server program.

These names describe roles in an exchange. If the photo service asks a separate identity service for information, the photo service is the client in that conversation. Before returning a private album, it still needs the authentication and authorization checks you've already met.

A link gives the browser an address, or URL, to work with. Consider this fictional album address. It is an example to read, not a request to send.

https://photos.example:443/albums/42?view=grid#photo-7

The host directs the request to a particular name, while the path identifies what is requested there. A query supplies additional values, each written as a name and a value joined by =, with & between them. Those values can be edited by whoever makes the request, so the service must validate them.

Some characters already have a job in an address: / separates the parts of a path, and ?, & and # start or separate other parts. A value can contain one of them without being mistaken for part of the address by writing it as % followed by a two-character code. Inside a query value, & and # must be written this way, because they would end the value or the query. / and : are allowed there as they are, but many programs encode them too: / becomes %2F and : becomes %3A, so the path /albums/42 written as a query value is often %2Falbums%2F42. This is percent-encoding, and the service decodes the value before it uses it.

Sign-in pages often carry a value like that. Opening https://photos.example/sign-in?continue=%2Falbums%2F42 asks the service to sign Ava in and then take her to album 42. Anyone can write such a link, including one whose continue value is an address on a look-alike site. If the service sent people on to whatever address it was given, Ava could check that the sign-in page was genuine, sign in, and land on an attacker's copy that asks for her password again. A service that forwards people to any address it is handed has an open redirect. A careful service checks the destination and accepts only places it recognizes, such as paths on its own host. Anything else is replaced with a safe default page.

The fragment, after #, stays in the browser instead of being sent to the server. It might tell the browser where to scroll or supply a value to code running in the page. A value in the fragment reaches the page without ever arriving at the server, while a value in the query is sent with every request for that address and can end up in the server's records of those requests.

The browser needs a network address for the hostname. The Domain Name System, or DNS, resolves names to addresses that computers can use, including numeric IP addresses. DNS keeps records for each name. One record might give the name's IP address; another might point the name at a different name, such as one belonging to a hosting provider.

Each part of a hostname between dots is a label, and the labels are read from the end. accounts.photos.example sits under photos.example, which sits under example. A name under another one, like accounts.photos.example under photos.example, is a subdomain of it. A similar-looking spelling under another ending is a different name. Seeing familiar words somewhere in an address is not enough.

Control can also be divided. A hosting service may give unrelated customers names such as alice.pages.example and bob.pages.example. Browsers use a list of public suffixes to help identify boundaries beneath which names may be independently registered or controlled. The list is not part of DNS. It is a public file that volunteers maintain, and browsers ship a copy of it with their updates. A company that gives unrelated customers names under its own domain, as the hosting service does with pages.example, asks to have that domain added. The registrable domain is the suffix plus the label immediately to its left. To find it in an address, take the host, find the longest public suffix at its end, and keep one more label. The scheme, port, path, query and fragment play no part.

Browsers use the registrable domain to decide which names belong to the same site. photos.example and accounts.photos.example share one registrable domain, so they are one site. Because pages.example is a public suffix, alice.pages.example and bob.pages.example are two different sites, as they should be for two unrelated customers. Several browser protections for signed-in people follow this boundary.

Before Ava sends her password, she needs a protected connection to the intended service. The https scheme asks the browser to use Transport Layer Security, or TLS.

To set up the connection, the server presents a certificate: a statement naming the hostnames the server may use, issued by a certificate authority. That is an organization browsers trust to check who controls a name before vouching for it. The browser checks that the certificate comes from an authority it trusts, is within its validity dates, and names the hostname it requested.

A certificate is public, so anyone could copy one. Presenting it is not enough. The server must also prove that it holds a secret value that belongs with the certificate and never leaves the server. Only then does the browser treat the connection as protected for that name. The connection protects messages against reading and alteration in transit.

This doesn't make every site using HTTPS trustworthy. A look-alike site can have a valid certificate for its own name. The browser is checking the name you requested, not deciding whether it was the name you intended.