Clients and servers MAY implement and use this extension to verify data integrity. In this case the server MUST add the checksum element to the TUS-Extension header.
A client MAY include the Content-MD5 header and its appropriate value in a PATCH request.
Once all the data has been received by the server it MUST verify the uploaded chunk against the provided checksum. If the verification succeeds the server continues with processing the data. In the case of mismatching checksums the server MUST abort handling the request and MUST send the tus-specific 460 Checksum Mismatch status code. In addition the file and its offsets MUST not be updated.
If the hash cannot be calculated at the beginning of the upload it MAY be included as a trailer. If the server can handle trailers, this behavior MUST be promoted by adding the checksum-trailer element to the TUS-Extension header.
Trailers, also known as trailing headers, are headers which are sent after the request's body has been transmitted already. Following RFC 2616 they must be announced using the Trailer header and are only allowed in chunked transfers.
Request:
PATCH /files/17f44dbe1c4bace0e18ab850cf2b3a83
Content-Length: 40
Offset: 0
TUS-Resumable: 1.0.0
Content-MD5: vVgjt92XwLTGjdkIiNdlSw==
Die Würde des Menschen ist unantastbar.
Response:
204 No Content
TUS-Resumable: 1.0.0
can not -> cannot
" included as a trailer" -- Do you think it will be clear what is meant as the trailer? Maybe add another example? Btw, a sentence describing the scenario showed by the included example would be nice.
"Once all the data has be sent to the server latter one MUST ..." -> "Once all the data has been received by the server, it MUST ..."
"If the verification succeeds the server MUST continue with processing the data." -- I would skip this sentence. It is IMHO clear what to do when checksum is correct. Or I would skip the MUST word so it doesn't seem like a requirement of the extension. Maybe just say "the server continues with processing".
The rest is great.