Code change:
incomplete successful transfer, the server MUST respond with a "409 (Conflict)" status code. <ins> 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.  These informational responses MUST NOT contain the "Location" header field. They MAY include the "Upload-Offset" header field with the current upload offset as the value to inform the client about the upload progress.  The same restrictions on the "Upload-Offset" header field in informational responses from the upload creation (upload-creation) apply. </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 success (e.g. "201 (Created)"), or when the response is a failure

Related discussion:
text: The text now also ensures that the client knows the upload resource URL before it receives a 104 with Upload-Offset. This avoids implementation issues where the client might free upload data before it knows the upload resource URL to resume the upload in cases of failure. Please let me know if these changes improve the draft's readability.
If we are adding strict incrementing requirement to 104 responses, should we also do so for plain offset retrieving?
I would prefer so for consistency.
In a message to the mailing list (URL), Austin Wright (NAME proposed to use informational responses to send information about the upload progress from the server to the client. During the Upload Creation Procedure and Upload Appending Procedure, the server could regularly send an informational response with the latest offset in the Upload-Offset header. The value should reflect the amount of data that has been received and safely stored by the server. This way, the client knows what data has been successfully transmitted and is not needed for resumption anymore. Any resources attached for this data (e.g. memory buffers) can be released then. In contrast, If the client only monitors which,data it has sent, it cannot be sure if the server properly stored it yet. There is a short example of this how communication could look like (note: it uses server-generated upload URLs (URL), but it could also be done using client-generated tokens, of course):
I think doing this is fine, and I agree that it has benefits as pointed out above. General guideline of HTTP is that servers are allowed to send any number of informational responses. There's no reason to not use that. Regarding the status code, I think we can reuse 104.
+1 Kazuho
I think we need some communication between client and server to enable this. The protocol is designed to avoid depending on 1xx status codes. Does the client need to explicitly opt in to this? Can the server opt out? What if the server doesn't support 1xx? If we want to keep this optional without adding a new header field, a possible design is: If the server wants to send periodic updates, it can start by doing so in the initial 104. The client can enable additional buffering behavior based on this information (but it might have already dropped some bytes by the initial 104). This is a server driven solution and the client won't be able to opt out.