aboutsummaryrefslogtreecommitdiff
path: root/archive/2022-01-04-proposal-get-endpoints
diff options
context:
space:
mode:
authorRasmus Dahlberg <rasmus@mullvad.net>2022-01-31 15:36:29 +0100
committerRasmus Dahlberg <rasmus@mullvad.net>2022-01-31 15:36:29 +0100
commitf8d61a93109656e89cbbdeae56ca778127a0eafe (patch)
treed1f935122336a93254fc869ebf63c7636a7d56ba /archive/2022-01-04-proposal-get-endpoints
parent9d5eee35a5fd7f145916043de3e94e14044946a7 (diff)
moved some persisted pads to proposal directory
See doc/proposals/2022-01-how-to-use-proposal-folder for details.
Diffstat (limited to 'archive/2022-01-04-proposal-get-endpoints')
-rw-r--r--archive/2022-01-04-proposal-get-endpoints46
1 files changed, 0 insertions, 46 deletions
diff --git a/archive/2022-01-04-proposal-get-endpoints b/archive/2022-01-04-proposal-get-endpoints
deleted file mode 100644
index cbe3170..0000000
--- a/archive/2022-01-04-proposal-get-endpoints
+++ /dev/null
@@ -1,46 +0,0 @@
-Proposal: change get-* endpoints that use HTTP post
-
-Background
----
-Right now we HTTP POST ASCII key-value pairs on these endpoints:
- * get-leaves
- * get-inclusion-proof
- * get-consistency-proof
-
-The original reason was to not have an additional parser, say, input-parameters
-with percent-encoding as part of the request URL.
-
-A major problem with this approach is that it will not be possible to benefit
-from HTTP caching. Debugging, with "URLs that reference data" also becomes more
-messy. You would have to say "I did printf <stuff> | curl ...".
-
-Proposal
----
-Change these endpoints so that they use HTTP GET. Encode input params in URL:
-
- <url>/get-leaves/10/20 # get leaves 10,11,...20
- <url>/get-consistency-proof/10/20 # proof from tree size 10 to 20
- <url>/get-inclusion-proof/10/<leaf hash in hex> # proof for tree size 10
-
-This notably avoids percent-encoding which is more messy.
-
-Notes
----
-We considered if it would be a good idea to re-use our ASCII parser for the
-portion of the URL that encodes input data. The basic idea would be that
-different "end of key" and "end of value" patterns could be used that are better
-suited for a URL.
-
-For example, instead of (=,\n) one could use ([,]) as ("end of key", "end of value").
- * get-leaves/start_size[10]end_size[12]
- * get-consistency-proof/old_size[12]new_size[14]
- * get-inclusion-proof/tree_size[10]leaf_hash[ab...ef]
-
-The reasons why we aborted this direction:
- * We can not think of any concrete security risk with the shorter '/' proposal.
- * There are very few parameters at play here, hard to confuse and quick
- feedback loop if you do. For example, "Error=start size must be smaller or
- equal to end size".
- * We can be sure that the '/' proposal will not introduce any wonky
- interoperability issues; picking a ("end of key", "end of value") would
- require much more care.