How a web request is handled

A request line is three tokens: the method, the path and the version. GET is the method, HTTP/1.1 is the version, and /hello is the path, which is the part a file server most often turns into a file name. Every one of those three tokens is chosen by the client, which is why none of them can be trusted on its own.

curl tidies a path by default, so a request for /../secret.txt becomes /secret.txt before it leaves the phone and the traversal never reaches the server. The --path-as-is option turns that tidy-up off, so the server sees exactly the path you typed. A real attacker would not use curl, but for a test on your own server you want the raw path to arrive intact.

The handler joins the path onto the root and opens the result. It never decodes percent escapes, so %2e%2e stays as the literal text percent two e percent two e, which is not the parent directory. The plain .. is a real directory name, so it works. This is exactly why a blocklist of .. is fragile: the attacker only has to find a spelling the blocklist forgot.

realpath follows every .. segment and every symbolic link and returns the file that would actually be opened. Comparing that resolved path against the root catches traversal however it was written, because the comparison happens after all the indirection has been removed. Checking the raw text instead means you are guessing at every spelling an attacker might use.