jiebi/CodeConvo huggingface dataset:
Code change:
Changes: s/tcpport/targetport/ (aligning with connect-udp) Remove support for multiple IPs and
NAME The discussion at IETF 119 leaned toward removing the multiple-IP mode entirely. Are you suggesting that we should keep it?
This PR contains two changes; I'm not making a suggestion with regard to multiple-IP mode, but I think aligning the variable names in the template makes sense. Did both get dropped, or is that being discarded because it's in the same PR?
OK, I've updated this PR to also drop the multiple-IP support entirely.
The target_host variable is only described vaguely. It should be defined more rigorously. For example, it doesn't specify whether IPv6 scope IDs are allowed or not. I'd recommend reusing the text from RFC 9298.
OK, I've opened to make the definition more rigorous.
Fixed by
The draft currently defines the "targethost" and "tcpport" variables. We should replace "tcpport" with "targetport" for consistency with connect-udp. This consistency isn't just cosmetic, it simplifies reusing the same URI template for both protocols.
The distinction is deliberate, precisely because it facilitates using a single URI template for both protocols. As discussed in , the client can use a single template for various purposes by inspecting the variables that it contains: "targetport" -> connect-udp "tcpport" -> connect-tcp "ipproto" -> connect-ip "dns" -> DoH Using the same name ("targetport") for TCP and UDP would add complexity for client implementors. Instead of being able to determine a priori_ whether a proxy supports TCP and UDP based on the template, the client would have to probe (and periodically re-probe) for this information and maintain dynamic state about which protocols are supported.
What you're saying is that a client can infer support for certain protocols based on the variables present in the URI template. That's not correct, or more precisely it wasn't specified for connect-udp, and it definitely doesn't work for connect-ip (in connect-ip the variables are optional).
OK, I see that it doesn't work for connect-ip, so connect-ip can only be supported by probing or with an out-of-band signal (or with an ecosystem restriction that connect-ip servers must support "target" and "ipproto"). It seems fine for connect-udp and connect-tcp because the variables are mandatory, so it would provide value to UDP+TCP clients (which seem likely to be common).
In that case we should state somewhere that passing around an URI template with these variables implies support for the corresponding mechanism. I'm not sure we'd get consensus on that though.
Thanks for the updates based on the discussion at 119

Related discussion:
text: In some cases, it is valuable to allow "connect-tcp" clients to reach "connect-tcp"-only proxies when using a legacy configuration method <del> that cannot convey a URI template.  To support this arrangement, </del> <ins> that cannot convey a URI Template.  To support this arrangement, </ins> clients SHOULD treat certain errors during classic HTTP CONNECT as indications that the proxy might only support "connect-tcp":
Code change:
This PR adds descriptions to all message exchange examples in the draft. It should make their purpose clearer and also help distinguish the two separate examples in section 4, as pointed out in .
Thank you all!
نزت
I think there's two different creation examples being shown in URL but the presentation of them isn't great and could be a source of confusion. If so, lets break them apart by having a short sentence before each example expliaining it.
Yes, these are two separate examples, which are confusing. Most of the example are in need of a proper description. I can open a PR to address this. Thank you!

Related discussion:
text: upload's final size is the "Content-Length" field value and the server MUST record it to ensure its consistency. <ins> The following example shows an upload creation.  The client transfers the entire 100 bytes in the first request.  The server generates two informational responses to transmit the upload resource's URL and progress information, and one final response to acknowledge the completed upload: The next example shows an upload creation, where only the first 25 bytes are transferred.  The server acknowledges the received data and that the upload is not complete yet: </ins> If the client received an informational response with the upload URL in the Location field value, it MAY automatically attempt upload resumption when the connection is terminated unexpectedly, or if a
Code change:
This PR adds descriptions to all message exchange examples in the draft. It should make their purpose clearer and also help distinguish the two separate examples in section 4, as pointed out in .
Thank you all!
نزت
I think there's two different creation examples being shown in URL but the presentation of them isn't great and could be a source of confusion. If so, lets break them apart by having a short sentence before each example expliaining it.
Yes, these are two separate examples, which are confusing. Most of the example are in need of a proper description. I can open a PR to address this. Thank you!

Related discussion:
text: The client MAY cancel the upload (upload-cancellation) after rejecting the offset. <ins> The following example shows an offset retrieval request.  The server indicates the new offset and that the upload is not complete yet: </ins> The client SHOULD NOT automatically retry if a client error status code between 400 and 499 (inclusive) is received.
Code change:
This PR adds descriptions to all message exchange examples in the draft. It should make their purpose clearer and also help distinguish the two separate examples in section 4, as pointed out in .
Thank you all!
نزت
I think there's two different creation examples being shown in URL but the presentation of them isn't great and could be a source of confusion. If so, lets break them apart by having a short sentence before each example expliaining it.
Yes, these are two separate examples, which are confusing. Most of the example are in need of a proper description. I can open a PR to address this. Thank you!

Related discussion:
text: upload's final size.  If they do not match, the server MUST reject the request with a "400 (Bad Request)" status code. <ins> The following example shows an upload append.  The client transfers the next 100 bytes at an offset of 100 and does not indicate that the upload is then completed.  The server acknowledges the new offset: </ins> The client MAY automatically attempt upload resumption when the connection is terminated unexpectedly, or if a server error status code between 500 and 599 (inclusive) is received.  The client SHOULD
Code change:
This PR adds descriptions to all message exchange examples in the draft. It should make their purpose clearer and also help distinguish the two separate examples in section 4, as pointed out in .
Thank you all!
نزت
I think there's two different creation examples being shown in URL but the presentation of them isn't great and could be a source of confusion. If so, lets break them apart by having a short sentence before each example expliaining it.
Yes, these are two separate examples, which are confusing. Most of the example are in need of a proper description. I can open a PR to address this. Thank you!

Related discussion:
text: If the server does not support cancellation, it MUST respond with a "405 (Method Not Allowed)" status code. <ins> The following example shows an upload cancellation: </ins> 8. 8.1.
Code change:
This PR adds explanations helping readers to understand when empty requests for upload creation or appending might be useful and why server should support them. Closes URL
The field definitions allow for a client to send 0-length content. Sometimes this is useful, other times it it might not be. For example, A client could perform upload creation by making a request content-length: 0 and with upload-complete:?0. This would allow it to test creation wihout having to commit to an upload in the same message. A client could attempt to append to append zero bytes. Is this useful or should we prohibit it? This is a cheap way to keep an upload "active". However, that might be a vector for abuse by allowing a client to cause server-side state commintment. Depending on what we decide, we might need some text in the security considerations.
Just to add to the two bullet points: This can also be used for clients/servers that do not support 1xx response by sending a 0 byte upload-complete: ?0 request to get the unique resource URL. This is for instance how does it. For cases where multiple upload-complete: ?0 requests are made, a final 0 byte upload-complete: ?1 request can be used to notify the server that the upload is complete. This can be useful in cases where the client wants to provide all the data before finalizing the upload to reduce the risk of losing the final response. I don't really see a use case for sending multiple 0 byte upload-complete: ?0 but there might be some?

Related discussion:
text: upload's final size is the "Content-Length" field value and the server MUST record it to ensure its consistency. <ins> The request content MAY be empty.  If the "Upload-Complete" header field is then set to true, the client intends to upload an empty entity.  An "Upload-Complete" header field is set to false is also valid.  This can be used to create an upload resource URL before transferring data, which can save client or server resources.  Since informational responses are optional, this technique provides another mechanism to learn the URL, at the cost of an additional round-trip before data upload can commence. The following example shows an upload creation.  The client transfers the entire 100 bytes in the first request.  The server generates two informational responses to transmit the upload resource's URL and progress information, and one final response to acknowledge the completed upload: The next example shows an upload creation, where only the first 25 bytes are transferred.  The server acknowledges the received data and that the upload is not complete yet: </ins> If the client received an informational response with the upload URL in the Location field value, it MAY automatically attempt upload resumption when the connection is terminated unexpectedly, or if a
Code change:
This PR adds explanations helping readers to understand when empty requests for upload creation or appending might be useful and why server should support them. Closes URL
The field definitions allow for a client to send 0-length content. Sometimes this is useful, other times it it might not be. For example, A client could perform upload creation by making a request content-length: 0 and with upload-complete:?0. This would allow it to test creation wihout having to commit to an upload in the same message. A client could attempt to append to append zero bytes. Is this useful or should we prohibit it? This is a cheap way to keep an upload "active". However, that might be a vector for abuse by allowing a client to cause server-side state commintment. Depending on what we decide, we might need some text in the security considerations.
Just to add to the two bullet points: This can also be used for clients/servers that do not support 1xx response by sending a 0 byte upload-complete: ?0 request to get the unique resource URL. This is for instance how does it. For cases where multiple upload-complete: ?0 requests are made, a final 0 byte upload-complete: ?1 request can be used to notify the server that the upload is complete. This can be useful in cases where the client wants to provide all the data before finalizing the upload to reduce the risk of losing the final response. I don't really see a use case for sending multiple 0 byte upload-complete: ?0 but there might be some?

Related discussion:
text: The client MAY cancel the upload (upload-cancellation) after rejecting the offset. <ins> The following example shows an offset retrieval request.  The server indicates the new offset and that the upload is not complete yet: </ins> The client SHOULD NOT automatically retry if a client error status code between 400 and 499 (inclusive) is received.
Code change:
This PR adds explanations helping readers to understand when empty requests for upload creation or appending might be useful and why server should support them. Closes URL
The field definitions allow for a client to send 0-length content. Sometimes this is useful, other times it it might not be. For example, A client could perform upload creation by making a request content-length: 0 and with upload-complete:?0. This would allow it to test creation wihout having to commit to an upload in the same message. A client could attempt to append to append zero bytes. Is this useful or should we prohibit it? This is a cheap way to keep an upload "active". However, that might be a vector for abuse by allowing a client to cause server-side state commintment. Depending on what we decide, we might need some text in the security considerations.
Just to add to the two bullet points: This can also be used for clients/servers that do not support 1xx response by sending a 0 byte upload-complete: ?0 request to get the unique resource URL. This is for instance how does it. For cases where multiple upload-complete: ?0 requests are made, a final 0 byte upload-complete: ?1 request can be used to notify the server that the upload is complete. This can be useful in cases where the client wants to provide all the data before finalizing the upload to reduce the risk of losing the final response. I don't really see a use case for sending multiple 0 byte upload-complete: ?0 but there might be some?

Related discussion:
text: upload's final size.  If they do not match, the server MUST reject the request with a "400 (Bad Request)" status code. <ins> The request content MAY be empty.  If the "Upload-Complete" field is then set to true, the client wants to complete the upload without appending additional data. The following example shows an upload append.  The client transfers the next 100 bytes at an offset of 100 and does not indicate that the upload is then completed.  The server acknowledges the new offset: </ins> The client MAY automatically attempt upload resumption when the connection is terminated unexpectedly, or if a server error status code between 500 and 599 (inclusive) is received.  The client SHOULD
Code change:
This PR adds explanations helping readers to understand when empty requests for upload creation or appending might be useful and why server should support them. Closes URL
The field definitions allow for a client to send 0-length content. Sometimes this is useful, other times it it might not be. For example, A client could perform upload creation by making a request content-length: 0 and with upload-complete:?0. This would allow it to test creation wihout having to commit to an upload in the same message. A client could attempt to append to append zero bytes. Is this useful or should we prohibit it? This is a cheap way to keep an upload "active". However, that might be a vector for abuse by allowing a client to cause server-side state commintment. Depending on what we decide, we might need some text in the security considerations.
Just to add to the two bullet points: This can also be used for clients/servers that do not support 1xx response by sending a 0 byte upload-complete: ?0 request to get the unique resource URL. This is for instance how does it. For cases where multiple upload-complete: ?0 requests are made, a final 0 byte upload-complete: ?1 request can be used to notify the server that the upload is complete. This can be useful in cases where the client wants to provide all the data before finalizing the upload to reduce the risk of losing the final response. I don't really see a use case for sending multiple 0 byte upload-complete: ?0 but there might be some?

Related discussion:
text: If the server does not support cancellation, it MUST respond with a "405 (Method Not Allowed)" status code. <ins> The following example shows an upload cancellation: </ins> 8. 8.1.
Code change:
This PR adds explanations helping readers to understand when empty requests for upload creation or appending might be useful and why server should support them. Closes URL
The field definitions allow for a client to send 0-length content. Sometimes this is useful, other times it it might not be. For example, A client could perform upload creation by making a request content-length: 0 and with upload-complete:?0. This would allow it to test creation wihout having to commit to an upload in the same message. A client could attempt to append to append zero bytes. Is this useful or should we prohibit it? This is a cheap way to keep an upload "active". However, that might be a vector for abuse by allowing a client to cause server-side state commintment. Depending on what we decide, we might need some text in the security considerations.
Just to add to the two bullet points: This can also be used for clients/servers that do not support 1xx response by sending a 0 byte upload-complete: ?0 request to get the unique resource URL. This is for instance how does it. For cases where multiple upload-complete: ?0 requests are made, a final 0 byte upload-complete: ?1 request can be used to notify the server that the upload is complete. This can be useful in cases where the client wants to provide all the data before finalizing the upload to reduce the risk of losing the final response. I don't really see a use case for sending multiple 0 byte upload-complete: ?0 but there might be some?

Related discussion:
text: waiting for the upload to complete before scanning a full file, or disabling resumable uploads. <ins> Resumable uploads are vulnerable to Slowloris-style attacks SLOWLORIS.  A malicious client may create upload resources and keep them alive by regularly sending "PATCH" requests with no or small content to the upload resources.  This could be abused to exhaust server resources by creating and holding open uploads indefinately with minimal work. Servers SHOULD provide mitigations for Slowloris attacks, such as increasing the maximum number of clients the server will allow, limiting the number of uploads a single client is allowed to make, imposing restrictions on the minimum transfer speed an uploads is allowed to have, and restricting the length of time an upload resource can exist. </ins> 11. IANA is asked to register the following entries in the "Hypertext
Code change:
A server might allow GET requests to be sent to an upload resource and serve content, in which case a 200 status code is more appropriate for responses to HEAD requests. This PR lifts the requirement that a successful response must be a 200.
The current draft requires the server to respond with a 204 No Content status code for HEAD requests: [...] If the server considers the upload resource to be active, it MUST respond with a 204 (No Content) status code. This restriction is too strict and does not allow the server to respond with a 200 OK. Since the HEAD requests for resumable uploads do not include any specific additional header field, the server cannot tell apart whether a HEAD request is used for resumable uploads or used for starting a download, for example. For example, a server might allow to download the uploaded file through a GET request to the upload URL. HEAD requests to this URL should then return the same status code (e.g. 200) and header fields as the GET request would do. But the draft requires a server to always respond with 204, leading to a conflict. Can we also allow 200 for HEAD responses?
I think this would be a good change to the spec. Maybe use similar language as with PATCH, where we allow the entire 2xx range but have a recommended status code? I don't think this would be an issue for any client. Is this a typo? Should be "... 200 for HEAD..."? >Can we also allow 204 for HEAD responses?
That's correct. Thank you for pointing out

Related discussion:
text: fields by responding with a "400 (Bad Request)" status code. If the server considers the upload resource to be active, it MUST <del> respond with a "204 (No Content)" status code.  The response MUST include the "Upload-Offset" header field, with the value set to the current resumption offset for the target resource.  The response MUST include the "Upload-Complete" header field; the value is set to true only if the upload is complete. </del> <ins> respond with a "204 (No Content)" or "200 (OK)" status code.  The response MUST include the "Upload-Offset" header field, with the value set to the current resumption offset for the target resource. The response MUST include the "Upload-Complete" header field; the value is set to true only if the upload is complete. </ins> An upload is considered complete only if the server completely and successfully received a corresponding creation request (upload-
Code change:
allows another status code to be returned for offset retrieval requests. This might break interoperability between existing implementation, so this PR bumps the interop version to make this change more visible.

Related discussion:
text: 4.2. <del> The current interop version is 4. </del> <ins> The current interop version is 5. </ins> Client implementations of draft versions of the protocol MUST send a header field "Upload-Draft-Interop-Version" with the interop version
Code change:
There were a few cases of the section linking to itself, which I find distracting, so lets remove them.
Good catch, thank you!

Related discussion:
text: The client MUST NOT start more than one append (upload-appending) based on the resumption offset from a single offset retrieving <del> (offset-retrieving) request. </del> <ins> request. </ins> In order to prevent HTTP caching, the response SHOULD include a "Cache-Control" header field with the value "no-store".
Code change:
There were a few cases of the section linking to itself, which I find distracting, so lets remove them.
Good catch, thank you!

Related discussion:
text: The server SHOULD respect representation metadata received during creation (upload-creation) and ignore any representation metadata <del> received from appending (upload-appending). </del> <ins> received from appending. </ins> If the server does not consider the upload associated with the upload resource active, it MUST respond with a "404 (Not Found)" status
Code change:
There were a few cases of the section linking to itself, which I find distracting, so lets remove them.
Good catch, thank you!

Related discussion:
text: upload resource in parallel.  This helps avoid race conditions, and data loss or corruption.  The server is RECOMMENDED to take measures to avoid parallel upload transfers: The server MAY terminate any <del> creation (upload-creation) or append (upload-appending) for the same upload URL.  Since the client is not allowed to perform multiple transfers in parallel, the server can assume that the previous attempt has already failed.  Therefore, the server MAY abruptly terminate the previous HTTP connection or stream. </del> <ins> creation (upload-creation) or append for the same upload URL.  Since the client is not allowed to perform multiple transfers in parallel, the server can assume that the previous attempt has already failed. Therefore, the server MAY abruptly terminate the previous HTTP connection or stream. </ins> If the offset indicated by the "Upload-Offset" field value does not match the offset provided by the immediate previous offset retrieval