From 5646c29598d4b4b9055c35c592909c0abef475ee Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=B6rn=20Friedrich=20Dreyer?= Date: Thu, 23 Apr 2020 11:54:22 +0200 Subject: [PATCH] Clarify OPTIONS requests wrt Tus-Rusumabl and Tus-Version headers (#153) From https://tus.io/protocols/resumable-upload.html#options > A successful response indicated by the `204 No Content` or `200 OK` status MUST contain the `Tus-Version` header. It MAY include the `Tus-Extension` and `Tus-Max-Size` headers. > > The Client SHOULD NOT include the `Tus-Resumable` header in the request and the Server MUST ignore the header. From https://tus.io/protocols/resumable-upload.html#tus-resumable > The `Tus-Resumable` header MUST be included in every request and response except for `OPTIONS` requests. The value MUST be the version of the protocol used by the Client or the Server. > > If the version specified by the Client is not supported by the Server, it MUST respond with the `412 Precondition Failed` status and MUST include the `Tus-Version` header into the response. In addition, the Server MUST NOT process the request. So we should omit the `Tus-Resumable` header from the OPTIONS request and clarify the example --- protocol.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/protocol.md b/protocol.md index 8a01896..d74a8a0 100644 --- a/protocol.md +++ b/protocol.md @@ -252,7 +252,7 @@ Server MUST ignore the header. ##### Example This example clarifies the response for an `OPTIONS` request. The version used -in both, request and response, is `1.0.0` while the Server is also capable of +in the response is `1.0.0` while the Server is also capable of handling `0.2.2` and `0.2.1`. Uploads with a total size of up to 1GB are allowed and the extensions for [Creation](#creation) and [Expiration](#expiration) are enabled. @@ -527,7 +527,6 @@ checksum algorithm and the Base64 encoded checksum separated by a space. ``` OPTIONS /files HTTP/1.1 Host: tus.example.org -Tus-Resumable: 1.0.0 ``` **Response**: