I work on OnePassApps, the team behind app.onepassapps.com, so this is our own site. Every answer below was measured against it today, 9 November 2026, with plain HTTPS requests from outside the browser: no session, no cookies, no JavaScript.
The question is narrow. Take seven real paths on our site and misspell each of them ten different ways. Which spellings still land on the page, which get redirected, and which end up on the miss document? The short answer is that the router is forgiving about slashes and unforgiving about everything else - and that it will not resolve a dot-segment for you.
What I sent
84 GETs in all. Seventy of them are the matrix: seven paths, ten spellings each. The seven were an app page, the guide for it, a second app page, its guide, a studio page, the vote board and the plans page, so the set spans every kind of page the site serves. The other fourteen are a separate check on the query string, at the end.
One detail of the method decides half the results. curl rewrites a path containing a dot-segment before it goes on the wire, so a request for /apps/paperkit/x/../paperkit would quietly become /apps/paperkit/paperkit and the server would never see what I typed. Every request below was sent with --path-as-is, and I read the request line back out of curl's own verbose log to confirm what the server actually received.
The ten spellings
Every answer below held for all seven paths. The byte counts are the ones for /apps/paperkit, which served 18,687 bytes.
| Spelling of /apps/paperkit | Status | What comes back |
|---|---|---|
| /apps/paperkit | 200 | the page itself, 18,687 bytes |
| //apps/paperkit | 200 | the same page, the same byte count, and the canonical tag still naming the clean URL |
| /apps/paperkit/ | 308 | a relative Location header pointing at /apps/paperkit |
| /apps/paperkit.html | 308 | a relative Location header pointing at /apps/paperkit |
| /apps/paperkit/x/../paperkit | 404 | the miss document |
| /APPS/PAPERKIT | 404 | the miss document |
| /apps/paperkit. | 404 | the miss document |
| /apps/paperkit%20 | 404 | the miss document |
| /%2Fapps/paperkit | 404 | the miss document |
| /apps/paperkit/index.html | 404 | the miss document |
The router folds a leading slash and ignores a dot-segment
//apps/paperkit is the forgiving one. It answers 200, the byte count is identical to the clean request, and both the canonical link tag and the og:url still name https://app.onepassapps.com/apps/paperkit, so the extra slash leaves no trace in the page it serves.
The detour through a parent segment is not treated the same way. /apps/paperkit/x/../paperkit is the same path on paper, and it answers 404. So the router will collapse an extra slash but will not walk back up the tree for you: a dot-segment inside the path is a miss, not a shortcut. The same is true of an encoded leading slash - /%2Fapps/paperkit answers 404 rather than being decoded into /apps/paperkit.
Two spellings redirect, and both point at the clean path
The trailing slash and the .html suffix answer 308 on all seven, and the Location header is relative, pointing at the extensionless path rather than at a full address. We have written about both before - the trailing slash in our tracking-link post, the .html suffix in our routing-extension post - so this run is mostly the confirmation that neither has changed: seven of seven, the same answer, the same header shape.
Six spellings miss, and they share one document
Every miss answers 404 with the same document: 13,806 bytes on all 42 misses, the title "Page not found — OnePassApps", a robots tag of noindex, nofollow, an og:url of https://app.onepassapps.com/__not-found__, and Cache-Control: no-store. There is no canonical tag on it at all.
That document is not byte-stable between two requests, and it is worth knowing why. Two GETs for the same missing path differ, and every byte that differs sits inside Cloudflare's per-request email-obfuscation token - the hex in the /cdn-cgi/l/email-protection# link and the data-cfemail attribute. Normalise just those two values and the documents match byte for byte, whether the second request is for the same path or for a completely different one. The miss page is the same page every time; only the obfuscation token moves.
The size has moved since we last wrote about it. Our November posts measured this same document at 13,953 bytes; today's build serves 13,806. The title, the robots tag and the placeholder og:url have not changed.
The query string, checked again
The last fourteen requests asked each of the seven paths twice, once bare and once with a tracking query. All seven answered 200 both times, with exactly the same byte count as the bare request, and the same story about the obfuscation token applies: same document once the token is normalised. The query string does not become a second version of the page.
What this means if you share a link
- Two spellings land on the page as it is: the exact path, and the same path with an extra leading slash.
- Two spellings get a permanent redirect to the clean path: a trailing slash, and a .html suffix.
- Six spellings land on the miss document: a dot-segment, an upper-case path, a trailing dot, a trailing space, an encoded leading slash, and an /index.html inside the path.
So the rules worth remembering are short. Case matters, and so does every character in the middle of the path. A slash at the front is free, a slash at the end is a redirect, and a dot in the middle is a miss.
You can try it on the PDF Organiser, and the rest of the apps are listed at the app guides.
Limits
- One build, one day, 9 November 2026, measured with plain HTTPS from outside the browser: no session, no cookies, no JavaScript.
- Seven paths of the 56 in our sitemap, and ten spellings each. I did not run the other 49 paths through these spellings, and I make no claim about them.
- Byte counts belong to this build and will move when the pages change.
- I did not test other schemes, other hosts or other ports, and I did not watch what a browser does after a redirect.
Top comments (0)