commit f1fcd13732731a1fa02f79349a2f97f0dcdc1a95
parent 256705655f05c1eccf650e10582741a44b1d640d
Author: Christian Grothoff <christian@grothoff.org>
Date: Tue, 4 Aug 2026 13:55:42 +0200
we use 303, not 302
Diffstat:
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/design-documents/076-paywall-proxy.rst b/design-documents/076-paywall-proxy.rst
@@ -58,7 +58,7 @@ Steps:
* If such a cookie is set and valid, the request is
reverse-proxied to upstream. *Stop.*
- * Otherwise, an HTTP 302 Redirect to
+ * Otherwise, an HTTP 303 See Other to
``/.well-known/paivana/templates/$ID#$WEBSITE``
is returned. Here, ``$ID`` is the template ID and
``$WEBSITE`` is base64url-encoding of the full URL of
@@ -154,9 +154,9 @@ Alternatives
* Do not re-use the session ID mechanism but introduce some new concept.
This has the drawback of us needing additional tables and indicies,
and also the existing use of the session ID is very parallel to this one.
-* Instead of doing a 302 Redirect, cache control could have been achieved by
+* Instead of doing a 303 See Other, cache control could have been achieved by
specifying a "Vary: Cookie" HTTP header. We may combine these and use
- that to additionally enable caching of the 302 Redirect. The 302 solution
+ that to additionally enable caching of the 303 See Other. The 303 solution
has the advantage that there is only one page to cache per template, and
the disadvantage of an additional redirect. Note that this is purely
a frontend design choice, wallets and merchant backends work nicely with
