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

[Austin William Wright <[e-mail]>]

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.