Use HTTP POST for report uploads

[tgeoghegan]

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.

Previous description of this PR:
For that reason, and also consistency with the aggregation job and collection job request paths, hoist the report ID out of the upload request body and into the request path. We don't want to repeat the report ID twice in one request, so struct Report no longer includes a struct Metadata and instead just puts the time inline in Report. struct ReportMetadata is still used in InputShareAad and elsewhere in DAP, so its definition is not changed, just moved farther down the document, and we explain how to construct it from the report request path and body.

With this change, there is now a unique URI for each report uploaded to a DAP leader. However we do not add any requirement that an Aggregator support GET requests on that path, because not all DAP implementations will necessarily store enough per-report information to be able to respond to such a request with a complete struct Report. Implementations are free to do that, but can also respond with HTTP 204, 404, 410 or some other error if they wish. As these are well-established HTTP semantics, DAP doesn't need to spend any more ink on explaining them.

[branlwyd]

I think this change is fine. However, as discussed off-PR (pointed out by @simon-friedberger, I think), switching from PUT to POST might be a smaller change. Are there downsides to using POST?

[tgeoghegan]

I lean toward using PUT and changing the request path because:

1. It makes the report upload request path consistent with the aggregation job and collection job request paths, which include their respective unique job IDs.
2. Using PUT elegantly makes it clear that this request is idempotent and safe to retry (of course if we go to a POST we can just explain in the DAP text that it's an idempotent POST).
3. While this forces a wire-breaking change, I think we're going to do draft 10 of DAP anyway, and that will mean a wire-breaking change to update the HPKE domain separation strings. Making this change to request paths and message formats isn't zero risk, but I think it's a marginal lift for implementations if they're breaking wire compatibility anyway.

[wangshan]

@tgeoghegan I read through the mailing list but don't get why this change is necessary? it seems specifying idempotent POST will do the same? Will we ever have a good reason to support GET a report?

[wangshan]

Does ReportMetadata still have meaning? would it be simpler if we simply put reportID and time in InputShareAad?

[tgeoghegan]

struct ReportMetadata ends up being useful in the aggregation interaction (e.g. it goes into a ReportShare) so I think it's useful.

[tgeoghegan]

@tgeoghegan I read through the mailing list but don't get why this change is necessary? it seems specifying idempotent POST will do the same? Will we ever have a good reason to support GET a report?

I agree that this change is not necessary, in that the protocol will work fine if we do nothing, or if we switch to a POST request and otherwise change nothing. I laid out my arguments for this change above, and concede that my arguments are essentially esthetic.

FWIW I don't intend to move forward with this change until and unless we establish WG rough consensus for it. I'll be following up on the mailing list with some concise discussion points to move this and other topics forward.

[branlwyd]

For what it's worth, I think a POST is ultimately a smaller change that arrives at the desired behavior.

I don't see much use for a GET of uploaded reports, and implementations will plausibly delete report content as soon as possible to reduce storage costs (which would make GET not so useful).

[cjpatton]

@tgeoghegan please rebase when you have a moment

[cjpatton]

No objection to this change!

[tgeoghegan]

This change has been up for quite a while and it seems to me that the most popular option, by dint of its simplicity, is to change the request upload to using POST without changing the request path or the request body. Accordingly I'm repurposing this PR to make that change.

[cjpatton]

Works for me. I think this is slightly better because it's clearer that reports aren't necessarily GETable once they are PUT (or POSTed, now).

[branlwyd]

Suggested change

	`{helper}/tasks/{task-id}/aggregation_jobs/{report-id}` would be expanded into
	`{helper}/tasks/{task-id}/aggregation_jobs/{aggregation-job-id}` would be expanded into

(editorial nit)