Clarify role of Content-Location in HEAD response

Author: awwright

draft-ietf-httpapi-patch-byterange.md

@@ -326,9 +326,9 @@ As an alternative to using PUT to create a new resource, the contents of a resou
 
 A user-agent may also use PATCH to recover from an interrupted PUT request, if it was expected to create a new resource. The server will store the data sent to it by the user agent, but will not finalize the upload until the complete length of the document is known and received.
 
-1. The client makes a PUT or PATCH request to a URL, a portion of which is randomized, to be unpredictable to other clients. This first request creates the resource, and should include `Prefer: transaction=persist` (to continuously commit the upload) and `If-None-Match: *` (to verify the target does not exist). If a PUT request, the server reads the Content-Length header and stores the intended complete length of the document. If a PATCH request, the "Content-Range" field in the "message/byterange" patch is read for the complete length. The complete length may also be undefined, and defined in a later request.
+1. The client makes a PUT or PATCH request to a URL, a portion of which is randomized, to be unpredictable to other clients. This first request creates the resource, and should include `Prefer: transaction=persist` (to continuously persist the upload) and `If-None-Match: *` (to verify the target does not exist). If a PUT request, the server reads the Content-Length header and stores the intended complete length of the document. If a PATCH request, the "Content-Range" field in the "message/byterange" patch is read for the complete length. The complete length may also be undefined, and defined in a later request.
 
-2. If any request is interrupted, the client may make a HEAD request to determine how much, if any, of the previous response was stored, and resumes uploading from that point. The server will return 200 (OK), but this may only indicate the write has been saved; the server is not obligated to begin acting on the upload until it is complete.
+2. If any request is interrupted, the client may make a HEAD request to determine how much, if any, of the previous response was stored. A `Content-Length` response header indicates what the size of an equivalent GET request would have been. Since this will be content uploaded in the interrupted attempt, this is the offset where the next request can resume uploading from.
 
 3. If the client sees from the HEAD response that additional data remains to be uploaded, it may make a PATCH request to resume uploading. Even if no data was uploaded or the resource was not created, the client should attempt creating the resource with PATCH to mitigate the possibility of another interrupted connection with a server that does not save incomplete transfers. However if in response to PATCH, the server reports 405 (Method Not Allowed), 415 (Unsupported Media Type), or 501 (Not Implemented), then the client must resort to retrying the PUT request.