A link is a host with things attached, and almost every misreading of a link comes from putting the boundary between host and path in the wrong place.
The shape
Read left to right, a link has up to four parts and they always arrive in the same order. The scheme comes first and ends at the colon and two slashes. The host follows, running until the next slash, question mark or hash, whichever appears first. The path begins at that slash and continues to the end unless a query interrupts it. The query begins at a question mark and runs to the end.
One rule settles the part people get wrong. The host ends at the first slash after the scheme. Not the last slash, not the slash before something that looks like a domain, and not the slash that seems to divide the interesting half from the boring half. The first one. Everything after it is path, no matter what the path is made of, and a path is under the control of whoever operates the host in front of it.
- Field order
- scheme, then host, then path, then query
- Scheme
- letters, then
:// - Host boundary
- the first
/after the scheme ends the host - Path
- starts with
/, may hold further slashes, may be empty - Query
- introduced by one
?, then name and value pairs joined by& - Fragment
- anything after a
#, and never sent to the host
http://xxxxxxxxxxxxxxxxxxxxxxxxxxxx.onion/support/ticket/0123
scheme host pathThe query at the end
A query is optional, and when it is present it changes nothing about where the link goes. It carries values to the page the path already selected. Its shape is regular: one question mark, then pairs of name and value joined by equals signs, with ampersands between the pairs. Order inside a query is not meaningful to a reader, and repeated names are legal, so a query with the same name twice is odd rather than broken.
Two things about queries are worth holding on to. First, a question mark ends the host just as firmly as a slash does, so a link with no path at all can still have a query. Second, values inside a query are frequently escaped, which is why the percent encoding card exists and why a query can look far stranger than it is.
How to check it by eye
Finding the first slash
- Find the
://. Put a mental marker just after it. - Move right until the first
/,?or#. Everything between the marker and that character is the host, and it is the only part that decides where the request goes. - Read the host you just isolated, and only that. Ignore the rest of the line while you do it.
- Now look for an
@in the stretch you just read. If there is one, the host is what follows it, not what precedes it, and you have isolated the wrong text. - Check the tail for a
#. Anything after it is a jump target inside the page and never leaves your machine.
What a wrong shape means
The most instructive wrong shape is not malformed at all. It is a link whose host is one thing and whose path contains something that resembles a host. Those links are perfectly legal, which is exactly why they work on the eye. The path is just text; anything can be written in it, including a string that ends in .onion.
Host in front
http://xxxxxxxxxxxxxxxxxxxxxxxxxxxx.onion/orders/0123
the host is the onion string; the path is a page on itHost somewhere else
http://examplexxxx-mirrors.tld/examplexxxx.onion/orders
the onion string here is text inside a pathBoth lines are valid links. In the second, the request goes to the ordinary domain marked in red, and the onion looking part is a directory name on that domain, chosen by whoever runs it. The first slash is the only thing that separates the two readings.
A second trap needs no path at all. An @ before the first slash splits the host section: everything to the left of it is treated as user information and discarded, and the host is whatever sits to the right. A long and familiar looking string in front of the at sign is therefore decoration.
http://awazonth6ocz5cyos63czmh[...]qmvyd.onion@examplexxxx.tld/
the host is examplexxxx.tld; everything before the @ is ignoredA trailing slash is the opposite of a trap. A link ending in / and the same link without it point at the same place when there is no path, and where there is a path the difference is a matter of how the far end organises its pages. Neither version is more correct, and neither is a signal about anything.
What a correct shape does not prove
Say the parts are in order, the host is where you expected, and the path is plausible. That leaves all of this untouched.
- Where the path ends up. Paths are handled by the far end, which may serve anything at any path, or send you onward the moment you arrive.
- That the path means what it reads as. A directory called
ordersis called that because somebody typed it, and the word is not a description of what is served there. - That the link and its visible text agree. In a message or a page, the words you can see are separate from the destination, and only the destination matters.
- That the query is harmless. Values in a query are carried to the far end, and a link handed to you may carry values you did not choose.
- That the host is the one you meant. Reading the host correctly is a reading skill; whether that host is the right host is a different question this card cannot reach.
What this card is not
This card is about structure, not about the host itself. The rules for the host as a string are on the onion address card. Escaped characters inside a path or a query have their own card, and a host built to be misread has another. If the thing riding in the link is a token rather than a page reference, the relevant card is a link with a token inside it, because a token brings a lifetime with it and a path does not.