From f8d61a93109656e89cbbdeae56ca778127a0eafe Mon Sep 17 00:00:00 2001 From: Rasmus Dahlberg Date: Mon, 31 Jan 2022 15:36:29 +0100 Subject: moved some persisted pads to proposal directory See doc/proposals/2022-01-how-to-use-proposal-folder for details. --- archive/2022-01-04-proposal-get-endpoints | 46 ------------------------------- 1 file changed, 46 deletions(-) delete mode 100644 archive/2022-01-04-proposal-get-endpoints (limited to 'archive/2022-01-04-proposal-get-endpoints') 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 | curl ...". - -Proposal ---- -Change these endpoints so that they use HTTP GET. Encode input params in URL: - - /get-leaves/10/20 # get leaves 10,11,...20 - /get-consistency-proof/10/20 # proof from tree size 10 to 20 - /get-inclusion-proof/10/ # 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. -- cgit v1.2.3