Code change:
13. <del> A message might have a content coding, indicated by the "Content- Encoding" header field, and/or a transfer coding, indicated by the "Transfer-Encoding" header field (RFC9112), applied, which modify the representation of uploaded data in a message.  For correct interoperability, the client and server must share the same logic when counting bytes for the upload offset.  From the client's perspective, the offset is counted after content coding but before transfer coding is applied.  From the server's perspective, the offset is counted after the content's transfer coding is reversed but before the content coding is reversed. </del> <ins> Since the codings listed in "Content-Encoding" are a characteristic of the representation (see HTTP), both the client and the server always compute the upload offset on the content coded data (that is, the representation data).  Moreover, the content codings are retained throughout the entire upload, meaning that the server is not required to decode the representation data to support resumable uploads.  See DIGEST-FIELDS for more information. </ins> 14. <ins> Unlike "Content-Encoding" (see HTTP), "Transfer-Encoding" (see RFC9112) is a property of the message, not of the representation. Moreover, transfer codings can be applied in transit (e.g., by proxies).  This means that a client does not have to consider the transfer codings to compute the upload offset, while a server is responsible for transfer decoding the message before computing the upload offset.  Please note that the "Content-Length" header field cannot be used in conjunction with the "Transfer-Encoding" header field. 15. </ins> The integrity of an entire upload or individual upload requests can be verifying using digests from DIGEST-FIELDS.

Related discussion:
text: The definition of upload creation requests allows the client to include the entire file, some file data or no data at all. While we provide this flexibility, we don't give guidance on when which approach is best suited. This PR adds this missing piece and explains how an optimistic client can attempt to upload the file in one request and how a careful client uses a separate request for creating the upload. In addition, it also mentions how to transparently upgrade to resumable uploads, which wasn't explained in detail before. Let me know if you have any feedback on this.
Are "Optimistic Upload Creation" and "Upgrading To Resumable Uploads" the exact same way? Maybe the 3rd way could be checking first before uploading?
The way they are described right now they are similar, yes. In theory, an optimistic upload creation can also be used where the client doesn't upload the entire file, but just a large part of it (think 500 MB of a 10 GB file). When upgrading a non-resumable request to a resumable upload, this act of division is not allowed. But I am not sure if we should go into that much detail here. If not, then we can merge these two sections. Upload limits are a good point! With the careful upload, the client also knows the limits before sending the first PATCH request. The optimistic client must be prepared to receive a 104 response with limits that it has to adapt to. We can mention that a careful client may also send an OPTIONS request before hand if it deems that necessary.
I think upload-limit can just be enforced on the server side. If it sends a 104 and a 5xx response, the client would automatically retry. We have deployed a client-side implementation that is not aware of the upload-limit header field.
Thanks for all of your comments! I updated the PR to put the section about upgrading to resumable uploads under the optimistic upload creation since they are similar. I also added a brief mention of Upload-Limit and shortened the text a bit. Let me know if you think the text needs more adjustments.
Just a minor nit. Otherwise I think this is a very good addition and agree with NAME that we should add some text with regards to the .