From 8f1f29daf32e3bdc769ccc65938d421be923e56c Mon Sep 17 00:00:00 2001 From: Tim Geoghegan Date: Tue, 9 Jan 2024 11:52:18 -0800 Subject: [PATCH] Use HTTP POST for report uploads Per httpdir early review of DAP ([1]), it's inappropriate to use PUT for a resource that cannot later be GET. Change the HTTP method for report uploads to POST, and add a note making it clear that uploads are idempotent and safe to retry. [1]: https://datatracker.ietf.org/doc/review-ietf-ppm-dap-09-httpdir-early-nottingham-2023-12-29/ --- draft-ietf-ppm-dap.md | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/draft-ietf-ppm-dap.md b/draft-ietf-ppm-dap.md index 5990d198..2d5dcb1d 100644 --- a/draft-ietf-ppm-dap.md +++ b/draft-ietf-ppm-dap.md @@ -846,6 +846,9 @@ the following parameters associated with it: * A unique identifier for the VDAF in use for the task, e.g., one of the VDAFs defined in {{Section 10 of !VDAF}}. +Note that the `leader_aggregator_url` and `helper_aggregator_url` values may +include arbitrary path components. + In addition, in order to facilitate the aggregation and collect protocols, each of the Aggregators is configured with following parameters: @@ -880,9 +883,13 @@ to the following rules: value MUST be encoded in its URL-safe, unpadded Base 64 representation as specified in {{Sections 5 and 3.2 of !RFC4648}}. -For example, resource URI `{leader}/tasks/{task-id}/reports` might be expanded -into -`https://example.com/tasks/8BY0RzZMzxvA46_8ymhzycOB9krN-QIGYvg_RsByGec/reports` +For example, given a helper URL "https://example.com/api/dap", task ID "f0 16 34 +47 36 4c cf 1b c0 e3 af fc ca 68 73 c9 c3 81 f6 4a cd f9 02 06 62 f8 3f 46 c0 72 +19 e7" and an aggregation job ID "95 ce da 51 e1 a9 75 23 68 b0 d9 61 f9 46 61 +28" (32 and 16 byte octet strings, represented in hexadecimal), resource URI +`{helper}/tasks/{task-id}/aggregation_jobs/{aggregation-job-id}` would be +expanded into +`https://example.com/api/dap/tasks/8BY0RzZMzxvA46_8ymhzycOB9krN-QIGYvg_RsByGec/aggregation_jobs/lc7aUeGpdSNosNlh-UZhKA`. ## Uploading Reports {#upload-flow} @@ -966,7 +973,7 @@ at least twice the cache lifetime in order to avoid rejecting reports. ### Upload Request -Clients upload reports by using an HTTP PUT to +Clients upload reports by using an HTTP POST to `{leader}/tasks/{task-id}/reports`. The payload is a `Report`, with media type "application/dap-report", structured as follows: @@ -1007,6 +1014,9 @@ Aggregators MAY require Clients to authenticate when uploading reports (see {{client-auth}}). If it is used, HTTP client authentication MUST use a scheme that meets the requirements in {{request-authentication}}. +The handling of the upload request by the Leader MUST be idempotent as discussed +in {{Section 9.2.2 of !RFC9110}}. + To generate a report, the Client begins by sharding its measurement into input shares and the public share using the VDAF's sharding algorithm ({{Section 5.1 of !VDAF}}), using the report ID as the nonce: