../courses.php

The Browser's Role

BROWSER

90

Entering A Web Address

Why one letter's case in an address can send the avatar somewhere completely different.

A user means to visit example.com/Account but instead types example.com/account, lowercase. On many servers this loads a completely different page, or no page at all, even though a person reading both addresses side by side would say they obviously mean the same thing. Why would changing the case of one letter matter to a server when it clearly doesn't matter to a person?

A web address is not interpreted for its likely meaning, it is matched, by many servers, as an exact sequence of characters, where uppercase and lowercase letters are simply different characters. A person reading the two paths applies outside knowledge that they obviously refer to the same idea. The browser sending the address, and frequently the server receiving it, does no such interpretation at all, it just sends, and matches, exactly the characters it was given.

A web address, technically a URL, breaks into distinct parts: a scheme such as https, a host such as example.com, a path such as /account, and sometimes a query string after a question mark.

The browser does not understand or interpret what a path like /account represents. It simply sends that exact text to the server named in the host part, and the server alone decides what, if anything, that exact path corresponds to.

A query string, the part after a question mark, holds key-value pairs the way example.com/search?q=php holds a key, q, set to the value php. This is the exact mechanism behind reading submitted values on the server side, covered elsewhere in this curriculum.

Typing an address directly, clicking a link, and a page redirecting all ultimately produce the exact same kind of outgoing request. The address itself does not know or care how it was arrived at.

An address with no path at all, just a host such as example.com, is treated by most servers as shorthand for a specific default path, commonly the site's home page, rather than as an incomplete or broken request.

One address, broken into its component parts

https specifically tells the browser to use an encrypted connection to reach the host. The exact same address with http instead would still reach the same host, just without that encryption in place.

example.com is the only part of this address that decides which actual server receives the request at all. Everything after the host is sent to whichever single server that name resolves to.

/search is sent exactly as written, character for character, to that one server. The server alone decides what, if anything, a path spelled exactly this way corresponds to.

q=avatar&page=2 holds two separate key-value pairs, joined by an ampersand. A server reading this address can look up q and page independently, in any order, regardless of which one was written first.

The host part, example.com, is generally treated the same regardless of capitalization, while the path and query portions, on many servers, are matched as exact, case-sensitive text, which is the specific reason /search and /Search can behave completely differently.

The browser sends an address exactly as typed, with no autocorrection of meaning

A typo in a host name is not corrected or guessed at by the browser. It is sent exactly as typed, to whatever host that exact text happens to resolve to, which may be nothing at all, or, in rarer and riskier cases, an entirely different site that registered a similar-looking name on purpose.

A path's case sensitivity depends on the server, not on the browser or the address itself

Whether two differently-cased paths are treated as the same path or as two different ones is a decision made entirely by the server receiving the request. The browser sends both exactly as written either way, with no opinion of its own about whether the difference should matter.

Two query parameters with the same key can both arrive, and a server has to pick which one matters

An address such as example.com/search?page=1&page=2 is not invalid. It sends both page values to the server, and which one, if either, a server's own code actually reads back is a decision made entirely on the server's side, not something the address itself resolves.

Characters with special meaning in a URL need to be encoded to be sent literally

A search term that itself contains a space or an ampersand cannot be placed directly into a query string without confusing where one value ends and the next begins. Encoding it first, turning a space into its percent-encoded form for instance, is what lets that exact character be sent as data rather than being read as part of the URL's own structure.

The same address typed twice produces two separate, independent requests

Reloading a page, or typing the exact same address again, does not somehow reuse or refer back to the earlier request. It produces a brand new one, with no memory of the previous one at all, unless something like a cookie is separately carrying that memory along.

Placing an unencoded space directly into a query string

Encoding the space before placing it in the query string

When an AI tool produces a URL, three things are worth checking. First, does it handle special characters in a query value by encoding them rather than placing them in directly. Second, does it avoid assuming a path's capitalization is automatically ignored, since this depends entirely on the server. Third, does it correctly describe reloading or retyping an address as a brand new, independent request rather than a continuation of an earlier one.

Take this lecture's example address and change page=2 to page=3, then identify exactly which part of the address changed and which parts stayed identical.

Write an address with two query parameters sharing the same key, and predict which value, if either, a typical server-side script reading that key would receive.

Encode a query value containing both a space and an ampersand correctly, then explain why encoding the ampersand specifically matters.

Visit the exact same address twice in a row, and explain why this produces two separate requests rather than one request remembered twice.

Find a real website where changing the capitalization of a path produces a different result, and a different one where it does not, and explain why the two sites might behave differently.

Assuming a typo in an address will be corrected or guessed at by the browser, rather than sent exactly as typed to whatever it happens to resolve to.

Placing a space or other special character directly into a query string instead of encoding it first.

Assuming a path's capitalization never matters, when whether it matters at all depends entirely on the server receiving the request.

Treating a reloaded or retyped address as continuing an earlier request, rather than as a brand new, independent one.

Forgetting that everything after the host portion of an address is sent to one single server, decided entirely by the host, regardless of how the rest of the address is structured.

You can now break a web address down into its scheme, host, path, and query parts, and explain why the host alone decides which server receives a request. You can also explain why case sensitivity in a path is the server's decision, not the browser's, and why query values containing special characters need to be encoded first.