Code change:
upload append (upload-appending), and upload cancellation (upload- cancellation). <del> Once the upload resource is available, the target resource MAY send an informational response with a "104 (Upload Resumption Supported)" status code to the client while the request content is being uploaded.  In this informational response, the "Location" header field MUST be set to the upload resource. </del> <ins> Once the upload resource is available and while the request content is being uploaded, the target resource MAY send one or more informational responses with a "104 (Upload Resumption Supported)" status code to the client.  In the first informational response, the "Location" header field MUST be set to the URL pointing to the upload resource.  In subsequent informational responses, the "Location" header field MUST NOT be set.  An informational response MAY contain the "Upload-Offset" header field with the current upload offset as the value to inform the client about the upload progress.  In subsequent informational responses, the upload offset MUST NOT be smaller than in previous informational responses.  In addition, later offset retrievals (offset-retrieving) MUST NOT receive an upload offset that is less than the offset reported in the latest informational response, allowing the client to free associated resources. </ins> The server MUST send the "Upload-Offset" header field in the response if it considers the upload active, either when the response is a

Related discussion:
text: Based on the discussion in URL, this PR would allow servers to repeatedly generate 104 responses to inform the client about the upload progress. The formulation allows the client to free associated resources (e.g. file buffers) because the server guarantees that the upload offset will never be less than the last reported value. Closes URL
If this is not a mandatory part of the protocol, I wonder how the client would know that the server supports it. It's possible that the client has already forgot about the initial bytes beyond the first ACK when the ACK is received.
I don't think the client must know in advance whether the server will send these additional informational responses. This mechanism is an additional enhancement, but not much should be lost if the server does not implement it. Yes, that can happen, but this can also occur in the current draft version. If the client forgot bytes that come before the reported by the server, it cannot continue the upload. The only save way for the client to regularly forget data is by chunking the upload into multiple requests using and thereby getting a confirmation from the server about the new upload offset. The addition of 104 for progress information does not change much about this approach. If you want to be sure about the offset, you should chunk the upload. But the 104s provide a slight improvement, where the client can already forget data before the request is completed. In a sense, the client should never forget data before the request is completed or a 104 is received if the client wants to recover from upload failures. This PR should just be an enhancement for the client, but not pose any additional issues for it. Does that make sense?
Based on the feedback from and IETF 118, I adjust the text in this PR to clarify what header fields can be present in informational responses: Upload creation: Server may send one or more 104 responses The first 104 response must contain the Location header, subsequent responses must not. The Upload-Offset header is optional Upload appending: Server may send one or more 104 responses The 104 response must not contain the Location header. The Upload-Offset header is optional In theory, this allows a 104 to be generated with no Location or Upload-Offset header, but I don't see a reason against disallowing this.