From b3e3416b5c31dd6c35a4909d0ed618559b0bf24c Mon Sep 17 00:00:00 2001 From: Nils Goroll Date: Sun, 6 Sep 2020 18:58:51 +0200 Subject: [PATCH] Add optional Content-Location response header ... to inform the Client about the permanent location of completed uploads. This is motivated by the following use cases: * TUS servers may not implement storage themselves, such that the `Location` returned for a creation (POST) request be only transitional. * TUS servers may decide to change the storage location once the upload is complete, for example to * implement content-based naming (where the file name is some hash over the content) * name content based on type * or select paths by size The `Content-Location` header is already defined by the HTTP RFCs, so, stricly speaking, its use should be implicitly allowed and well defined. Yet, for TUS, it makes sense to allow use of this response header for additional HTTP verbs (e.g. `PATCH`) and it might help implementation interoperability to point it out. --- protocol.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/protocol.md b/protocol.md index d74a8a0..0cf6377 100644 --- a/protocol.md +++ b/protocol.md @@ -141,6 +141,7 @@ Tus-Resumable: 1.0.0 HTTP/1.1 204 No Content Tus-Resumable: 1.0.0 Upload-Offset: 100 +Content-Location: https://tus.example.org/storage/d41d8cd98f00b204e9800998ecf8427e ``` ### Headers @@ -191,6 +192,15 @@ interpreted as the request's method by the Server, if the header is presented. The actual method of the request MUST be ignored. The Client SHOULD use this header if its environment does not support the PATCH or DELETE methods. +#### Content-Location + +The Server MAY send a `Content-Location` header with any response once +the upload is complete to optionally indicate to the Client a new +location of the upload. + +See [RFC 7231 Section +3.1.4.2](https://httpwg.org/specs/rfc7231.html#header.content-location). + ### Requests #### HEAD