Original text:
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>  The server MUST send the "Upload-Offset" header field in the response if it considers the upload active, either when the response is a

Reviewer comments:
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. 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.
Or maybe URL
I'm not fussed on the specific response code value but the 102 seems deprecated, for whatever that means, and the linked wording seems at odds with the system design we want
It's not deprecated, but wasn't carried over to WebDAV-bis due to lack of implementations. It's in the registry, so it's a real HTTP status code. That said, I now agree it doesn't fit well, as 102 is for situations where the client is actually waiting for a response (as opposed to still sending).
I guess that's accurate to the historical record, after a very cursory delve into RFC 2518 and 4918. But I wonder how clear that interpretation is to the broader HTTP world. MDN has a perspective you might want to follow up on. Yeah this is where I'm hitting a hard edge. A registered status code, where the behaviour, the important stuff, is described in an obsoleted RFC doesn't really seem great.
FWIW, I would push back hard on that line of argument. The code is registered, so it's a valid status code. And yes, a spec that wants to use might want to either include an updated definition, or make sure the definition is moved to a separate new document.
I also think that 102 is OK to use here (but maybe a new status code is still warranted, see below). The 102 isn't depreciated as a bad idea or because of another better solution, it was merely omitted from recent updates to the WebDAV specification for lack of implementations. I imagine another specification could take over ownership of the definition/registration. I think the only reason I didn't specifically write 102 in my email is, I've to indicate "upload complete, the server is now performing additional processing" and it may be useful to distinguish this signal from "upload has been partially received and committed to storage". The former is probably closer to the intended usage, so it may still be good to mint a new status code for the latter usage. Alternatively, both cases might be distinguished by the HTTP fields that are returned, and maybe servers want to indicate both at the same time ("50% committed to disk, 20% processed").
I share the view that 102 does not fit very well here. It would be awkward to send an URI to which the missing part of the request should be sent, while indicating that "the server has accepted the complete request" (). If we are to choose from an existing status code, 100-continue might be a better choice, though I would prefer using a new status code considering that we did so in introducing 103. All 1xx codes are interim and therefore kind of implies continuation. We can burn a new status code for a particular case of contiuation, which Resumable Upload is.
I opened a PR for this in URL
I think this would be a good addition to the spec as long as it's not mandatory for the server to send this data. As previously stated in this thread It would help the client to discard in-memory data that is no longer required to resume. Would it make sense to also include the location header in the additional 104 responses? This would make the solution more robust in case one (or several) of the 104 responses get lost and the extra header field would not add any significant amount of extra bytes in each request.
Yes, this would be optional. I am unsure how big the benefit would actually be. This would only help if a 104 is lost without the connection being destroyed, so the HTTP response is still open and a subsequent 104 could be received. Maybe this is possible with HTTP/2 or HTTP/3, but I don't know that. Other than that, repeating Location would be redundant.
1xx response are allowed to be dropped by intermediaries. But I'm not aware of any that would drop some in a request. Typically they just swallow all or pass all.
NAME Is that so? I could be wrong but states that a proxy MUST forward 1xx responses unless the proxy itself requested the generation of the 1xx response.
I suspect what NAME meant to say is that some proxies do drop 1xx responses, whether they're allowed to or not. Also, some HTTP libraries consume all the 1xx responses without exposing them to the caller, even if the library itself doesn't do anything with that particular 1xx code; such a library is indistinguishable from a poorly-behaved intermediary.
My concern isn't so much proxies dropping one or more response as much as e.g. switching network and losing one or more of the 104 response (think spotty Wi-Fi moving over to 4G). Another input here would be consistency, especially if we add the header to the first 104. I agree that the benefit might not be huge but it's not zero either. It does however seem like the consensus in Prague was that this is not needed and I can get behind that.
One or more of the 104 responses could be dropped, along with the final response, due to the connection being interrupted, but selective 104s can't be dropped due to network issues. Clients need to deal with failed connections no matter what, so I don't see how this is an issue.
NAME Right, then this is a non-issue that can be skipped. I just wanted to bring it up so that we do not miss aspects. :)
Thanks for the feedback! I adjusted URL to clarify what header fields can be present in 104 responses.

Revised text:
upload append (upload-appending), and upload cancellation (upload- cancellation).  <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