W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2022

Idempotency-Key for resuming requests (TUS Resumable Uploads Protocol)

From: Austin William Wright <aaa@bzfx.net>
Date: Wed, 5 Oct 2022 16:07:29 -0700
Message-Id: <9CB21DA8-9DBD-429B-930A-E67774652B06@bzfx.net>
To: ietf-http-wg <ietf-http-wg@w3.org>
Hello HTTP WG,

It occurred to me that, in general, where a client wants resumable requests, it also wants those requests be idempotent. I noted the HTTP APIs WG is considering an Idempotency-Key header, and it seems to me these should be part of the same mechanism. Let me explain how that might work:

If the client sends an Idempotency-Key, then the server can respond with a 1xx (Resumption Supported) confirming that the key will be honored for resuming the request.

Clients that want resumption SHOULD send Idempotency-Key, but they don’t have to (for example, to minimize UA fingerprinting). If the client does not send Idempotency-Key, the server should still send 1xx (Resumption Supported) to assign the request an Idempotency-Key. But it doesn’t have to (for example, 1xx is filtered by gateways).

Then when the request is interrupted, the client may resume the request with the same URI and Idempotency-Key of the request being resumed. By defining a RESUME method, a client could attempt to send a RESUME request in the hopes the server supports resumption, even if it didn’t receive a 1xx response. (Using the same URI allows the server to partition incomplete requests/uploads by the resource URI. There should be little need to re-send the method, since the server must store the details of the original request anyways, but a header could be defined if such a need is found.)

I see few downsides with this technique. There’s some builtin redundancy so resumption will work even if one party is buggy, and if a new method is used, there’s no possibility that a server could misinterpret the request. Idempotency-Key would replace "Upload-Token” entirely.

Thoughts?

Thanks,

Austin.
Received on Wednesday, 5 October 2022 23:07:47 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:44:08 UTC