Code change:
knowledge of server support. The request MUST NOT include the "Upload-Offset" header or the <del> "Upload-Incomplete" header.  The server MUST reject the request with the "Upload-Offset" header or the "Upload-Incomplete" header by sending a "400 (Bad Request)" response. </del> <ins> "Upload-Complete" header.  The server MUST reject the request with the "Upload-Offset" header or the "Upload-Complete" header by sending a "400 (Bad Request)" response. </ins> If the server considers the upload associated with this upload URL active, it MUST send back a "204 (No Content)" response.  The response MUST include the "Upload-Offset" header set to the current resumption offset for the client.  The response MUST include the <del> "Upload-Incomplete" header which is set to true if and only if the upload is incomplete.  An upload is considered complete if and only if the server completely and successfully received a corresponding </del> <ins> "Upload-Complete" header which is set to true if and only if the upload is complete.  An upload is considered complete if and only if the server completely and successfully received a corresponding </ins> Upload Creation Procedure (upload-creation) or Upload Appending <del> Procedure (upload-appending) request with the "Upload-Incomplete" header being omitted or set to false. </del> <ins> Procedure (upload-appending) request with the "Upload-Complete" header being set to true. </ins> The client MUST NOT perform the Offset Retrieving Procedure (offset- retrieving) while the Upload Creation Procedure (upload-creation) or

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."