Code change:
complete, the server MUST acknowledge it by responding with a successful status code between 200 and 299 (inclusive).  Server is RECOMMENDED to use "201 (Created)" response if not otherwise <del> specified.  The response MUST NOT include the "Upload-Incomplete" header with the value of true. </del> <ins> specified.  The response MUST NOT include the "Upload-Complete" header with the value of false. </ins> If the request completes successfully but the entire upload is not <del> yet complete indicated by the "Upload-Incomplete" header, the server MUST acknowledge it by responding with the "201 (Created)" status code, the "Upload-Incomplete" header set to true. </del> <ins> yet complete indicated by the "Upload-Complete: ?0" header, the server MUST acknowledge it by responding with the "201 (Created)" status code, the "Upload-Complete" header set to false. </ins> If the client received an informational repsonse with the upload URL, it MAY automatically attempt upload resumption when the connection is

Related discussion:
text: Closes URL
NAME brought up that during the WG meeting that reusing Upload-Complete on requests and responses can be confusing. They don’t mean exactly the same thing: on the server means it has received the full upload, while on the client means the body it will send is a complete upload.
We discussed this internally and prepared a response: Upload-Complete is used on both requests and responses because it is symmetrical. Upon a typical successful transaction, an request results in an response, and an request results in an response. A server implementation can simply echo the field. However, they are also meanings that we can take advantage of. The presence on the request means it’s a resumable request, and the presence on the response is also a useful signal. Since we are upgrading regular uploads, there are cases where 4xx/5xx responses are intentional and we can't just eat it by attempting to resume. We would be much more confident that the response came from the real server rather than a middlebox which shouldn’t randomly add . The server can also use to terminate a request early if it does not care about the body, similar to the early response mechanism in HTTP/3.
I am having second thoughts about this as well. While debugging a server implementation, the naming of the headers also confused me for a moment (even though I wrote parts of the draft). The reason is that in a response (or how it is currently called) refers to the current state of the upload, while in a request refers to the potential state in the future, if the request completed successfully. I don't think that we have a general issue with the concept of and have to change much. But maybe a simple name change can help here already to alleviate the confusion. We could use for the response header to indicate that it represents the current state. And for request headers to indicate that process the request successfully will complete the upload. We loose the symmetry of the names in request and response, but maybe this makes their relation even clearer.
I think for both client and server works because it represents their own perspectives of the upload. For the client, sending means "the upload is complete on my end, I've included all the data to complete it."