Oops. My bad. As soon as I hit “Submit Comment” I remembered about using the URL for passing tokens, invoking scripts and applications (”apps” for the web 2.0 generation).

For example, I’m rather sure I always use AmeriCorps, but would usually type Powerpoint or Power Point.

I’d always cite ProQuest, but never HarperCollins, which is always Harper Collins.

Part of this is ignorance on my part (it’s SpongeBob SquarePants, not Spongebob Squarepants? Who knew?) but also a bit of an aesthetic or political choice when a “CamelCase” looks displeasing or stinks of corporate manipulation (there’s no way I’m switching to RadioShack.)

Yes, I know that. That’s also specified in the relevant standard.

Then your browser accesses the host using the IP address and the remainder of the URL; the host that gets the request treats the remainder of the URL as a filename under the hosted part of it’s operating system.

No it doesn’t. That is, it may well do that, most of the time, in practice, but that’s not what it’s doing in theory: an URL is simply a resource identifier; what the resource “means”, whether it represents a file (and, if so, how the file path is related to the URL string), an entry in a database, or whatever else you can think of, is up to its handler. FWIW, URL components can have associated data that can’t be mapped into the filesystem; e.g., something like http: //foo.com/xyz;abc=def,ghi=jkl/uvw;m=n — the “path” components are “xyz” and “uvw”; “abc”/”def” and “ghi”/”jkl” are non-path elements associated with the “xyz” component, etc.; it wouldn’t be legal to map it to a file named “uvw;m=n”, if you supported that URL.

The domain name is case insensitive. Mix capitals and lower case letters to your heart’s content – between the http[s]:// and the first following /.

The domain name is never used directly to access a file on a host computer. Instead, the browser sends the domain part to a Domain Name Server (DNS), to be translated to an IP (Internet Protocol) address – such as 70.254.231.87, for instance. The IP address uniquely identifies one single resource attached to the internet. Then your browser accesses the host using the IP address and the remainder of the URL; the host that gets the request treats the remainder of the URL as a filename under the hosted part of it’s operating system.

The Domain Name Server processes the name in a case-insensitive manner. That is why the domain name part of the URL is case insensitive (including CamelCase, or Pascal case, as Microsoft would have it, when the initial letter is upper case), and the following part is usually case sensitive.

A URL after the domain and ‘/’ is host-dependent. The common approach across all servers I know about today is to use actual (legal!) file system filenames and directory (folder) names as literals in the URL, evaluating to an actual filename at some point. If your host is windows based, Index.html and index.html will likely both pull up the same page. On Linux or Unix, it will not – the difference between ‘I’ and ‘i’ character in Unix or Linux is exactly the same difference as between ‘-’ and ‘_’ – they are different characters in every aspect, at least as used for file names, directory names, and URL’s.

The part of the URL might still contain upper case letters, but they should be treated as non-discretionary. If you change the case of the letters in the latter part of the URL, you will likely void the URL and fail to find a valid page.