Personal Catalogue: Django & PostgreSQL — Chapter 10, Exercise 2
====================================================

TASK
Explain, in your own words, why FORCE_SCRIPT_NAME is the real
Django-specific counterpart to the PHP variant's own
absolute-vs-relative-redirect problem — what underlying issue do both
actually solve?

SOLUTION / ANSWER

Both problems come from the exact same root cause: an application was
originally built assuming it lives at the web root ("/"), and it's
now being mounted at a sub-path ("/catalogue/") instead. Anything the
application generates that encodes its own location - a redirect URL,
a link, a form action - is wrong once that assumption stops being true,
unless something corrects it.

In the PHP variant (personal_catalogue_php_mysql_1_10.html), the
concrete failure is a hardcoded absolute redirect:

    header('Location: /add_item.php?status=success');

This string is built by hand, with no awareness of where the app is
actually mounted, so it always points at the web root regardless of
the real deployment path. The fix there is manual and per-call: either
prefix every such string with /catalogue, or rewrite it as a relative
path.

In the Django variant, the same underlying assumption exists, but it
lives inside Django's own {% url %} / reverse() machinery rather than
in hand-typed strings scattered across the codebase. FORCE_SCRIPT_NAME
fixes it once, at the framework level, because every URL Django
generates already funnels through that one shared mechanism.

WHY THIS WORKS AS AN ANSWER
----------------------------
It names the shared underlying problem (mounting an app that assumes
it owns the web root) before describing either fix, and explains why
the Django fix is structurally different (one framework-level setting)
rather than just asserting it's "better" without reasoning through why.