Exercise 1: Absolute-Path Traversal, Blocked Live — Possible Solution
====================================================================

THE TEST
------------------------------
    import urllib.parse
    secret_abs = os.path.join(SCRATCH, 'secret_outside_static.txt')

    # backslash-style (raw Windows path), URL-quoted
    quoted_abs = urllib.parse.quote(secret_abs)
    get('/static/' + quoted_abs)

    # forward-slash-style, URL-quoted
    quoted_abs2 = urllib.parse.quote(secret_abs.replace('\\', '/'))
    get('/static/' + quoted_abs2)

VERIFIED, REAL RESULT
------------------------------
    legitimate file, sanity check:                (200, b'hello from cli static file')
    absolute-path attempt (URL-quoted real path):  (404, b'404 Not Found')
    absolute-path attempt, forward-slash form:     (404, b'404 Not Found')

Both real absolute-path variants against the live CLI-served app were
blocked, exactly like the "../"-based attempts already verified earlier
in the chapter.

WHY THIS WORKS
------------------------------
safe_static_path() never actually looks at whether a string contains
"..", a leading "/", or a drive letter — it resolves the candidate path
to its real, canonical absolute form with os.path.realpath(), then
checks with os.path.commonpath() whether that real destination still
sits inside the real, resolved static root. An absolute path to a file
outside STATIC_DIR resolves to itself (realpath() on an already-absolute
path is close to a no-op) — and that real destination simply isn't
inside static_root, so commonpath() returns a shorter path than
static_root and the containment check correctly fails, returning None
regardless of whether the traversal was spelled with "..", an absolute
path, or a mix of both.

WHY THIS WORKS AS AN ANSWER
------------------------------
It tests genuinely different attack shapes than the ones already shown
in the chapter body (relative "../" traversal) — a full absolute path
requires no ".." segment at all, so it's worth confirming directly
rather than assuming the same fix covers it. Testing both a raw
Windows-style path and a forward-slash-normalized version also confirms
the fix isn't accidentally depending on which slash direction the
attacker happens to use.