jiebi/CodeConvo huggingface dataset:
Code change:
This includes changing the title, adjusting the language to be more generic, and adding a section with guidance for HTTP CONNECT.
Most of the considerations in optimistic-upgrade, which originally emerged from consideration of "connect-tcp", also apply to HTTP CONNECT. We should consider expanding the scope of the draft to cover that topic as well. cc NAME

Related discussion:
text: 2. <del> In HTTP/1.1, a client is permitted to send an "Upgrade" request header field (RFC9110) to indicate that it would like to use this connection for a protocol other than HTTP/1.1.  The server replies with a "101 (Switching Protocols)" status code if it accepts the protocol change.  However, that specification also permits the server to reject the upgrade request: </del> <ins> In HTTP/1.1, a single connection is often used for many requests, one after another.  After each request, the connection is returned to its initial state, ready to send more HTTP requests.  However, HTTP/1.1 also contains two mechanisms that allow the client to change the protocol used for the remainder of the connection. </ins> <del> This rejection of the upgrade is common, and can happen for a variety of reasons: </del> <ins> One such mechanism is the "Upgrade" request header field (RFC9110), which indicates that the client would like to use this connection for a protocol other than HTTP/1.1.  The server replies with a "101 (Switching Protocols)" status code if it accepts the protocol change. The other mechanism is the HTTP "CONNECT" method.  This method indicates that the client wishes to establish a TCP connection to the specified host and port.  The server replies with a 2xx (Successful) response to indicate that the request was accepted and a TCP connection was established.  After this point, the TCP connection is acting as a TCP tunnel, not an HTTP/1.1 connection. Both of these mechanisms also permit the server to reject the request.  For example, RFC9110 says: and Rejections are common, and can happen for a variety of reasons.  An "upgrade" request might be rejected if: </ins> The server does not support any of the client's indicated Upgrade Tokens (i.e., the client's proposed new protocols), so it
Code change:
This includes changing the title, adjusting the language to be more generic, and adding a section with guidance for HTTP CONNECT.
Most of the considerations in optimistic-upgrade, which originally emerged from consideration of "connect-tcp", also apply to HTTP CONNECT. We should consider expanding the scope of the draft to cover that topic as well. cc NAME

Related discussion:
text: client and server have distinct interpretations of the data that flows between them. <del> If the server accepts an HTTP Upgrade, it interprets the subsequent bytes in accordance with the new protocol.  If it rejects the upgrade, it interprets those bytes as HTTP/1.1.  However, the client doesn't know which interpretation the server will take until it receives the server's response status code.  If it uses the new protocol optimistically, this creates a risk that the server will interpret attacker-controlled data in the upgraded protocol as an </del> <ins> If the server accepts a protocol transition request, it interprets the subsequent bytes in accordance with the new protocol.  If it rejects the request, it interprets those bytes as HTTP/1.1.  However, the client doesn't know which interpretation the server will take until it receives the server's response status code.  If it uses the new protocol optimistically, this creates a risk that the server will interpret attacker-controlled data in the new protocol as an </ins> additional HTTP request issued by the client. <del> As a trivial example, consider an upgraded protocol in which the entire post-upgrade content might be freely attacker-controlled (e.g., "connect-tcp" I-D.ietf-httpbis-connect-tcp).  If the client is authenticated to the server using a connection-level authentication method such as TLS Client Certificates, the attacker could send an HTTP/1.1 POST request in the post-upgrade payload.  If the client delivers this payload optimistically, and the upgrade request fails, the server would interpret the payload as a subsequent authenticated </del> <ins> As a trivial example, consider an HTTP CONNECT client providing connectivity to an untrusted application.  If the client is authenticated to the proxy server using a connection-level authentication method such as TLS Client Certificates, the attacker could send an HTTP/1.1 POST request for the proxy server at the beginning of its TCP connection.  If the client delivers this data optimistically, and the CONNECT request fails, the server would misinterpret the application's data as a subsequent authenticated </ins> request issued by the client. 3.2.
Code change:
This includes changing the title, adjusting the language to be more generic, and adding a section with guidance for HTTP CONNECT.
Most of the considerations in optimistic-upgrade, which originally emerged from consideration of "connect-tcp", also apply to HTTP CONNECT. We should consider expanding the scope of the draft to cover that topic as well. cc NAME

Related discussion:
text: A related category of attacks use protocol disagreement to exploit vulnerabilities in the server's request parsing logic.  These attacks apply when the HTTP client is trusted by the server, but the post- <del> upgrade data source is not.  If the server software was developed </del> <ins> transition data source is not.  If the server software was developed </ins> under the assumption that some or all of the HTTP request data is not <del> attacker-controlled, optimistic use of HTTP Upgrade can cause this </del> <ins> attacker-controlled, optimistic transmission can cause this </ins> assumption to be violated, exposing vulnerabilities in the server's HTTP request parser. 4. <del> If the server rejects the upgrade, the connection can continue to be used for HTTP/1.1.  There is no requirement to close the connection in response to an upgrade rejection, and keeping the connection open has performance advantages if additional HTTP requests to this server are likely.  Thus, it is normally inappropriate to close the connection in response to a rejected upgrade. </del> <ins> If the server rejects the transition request, the connection can continue to be used for HTTP/1.1.  There is no requirement to close the connection in response to a rejected transition, and keeping the connection open has performance advantages if additional HTTP requests to this server are likely.  Thus, it is normally inappropriate to close the connection in response to a rejected transition. </ins> 5.
Code change:
This includes changing the title, adjusting the language to be more generic, and adding a section with guidance for HTTP CONNECT.
Most of the considerations in optimistic-upgrade, which originally emerged from consideration of "connect-tcp", also apply to HTTP CONNECT. We should consider expanding the scope of the draft to cover that topic as well. cc NAME

Related discussion:
text: 7. <ins> Clients that send HTTP CONNECT requests on behalf of untrusted TCP clients MUST wait for a 2xx (Successful) response before sending any TCP payload data. To mitigate vulnerabilities from any clients that do not conform to this requirement, proxy servers MAY close the underlying connection when rejecting an HTTP CONNECT request, without processing any further data sent to the proxy server on that connection.  Note that this behavior may impair performance, especially when returning a "407 (Proxy Authentication Required)" response. 8. </ins> This document has no IANA actions.
Code change:
As discussed in URL, this requires the upload offset to not decrease. The server is not allowed to "forget" data appended to an upload. The benefit is that it allows a client to reduce the amount of data buffered while the upload is ongoing as it receives acknowledgements from the server that data has been stored permanently and will not have to be retransmitted. Closes URL
URL added the requirement that the offset reported in 104 informational responses must not decrease over time. For example, it is not allowed that one 104 response includes and the next includes . For now, this requirement is not mentioned for responses to offset retrieval responses. As NAME mentioned in URL, we should add this rule there as well. Maybe it also makes sense to move this into a more central section of the document, so that we don't have to repeat this rule trice (upload creation, upload appending, and offset retrieval).
Thinking about this a bit more, progress reporting and offset retrieving are different enough that adding this requirement to offset retrieving might not actually make sense. In a single append, it's impossible for progress to go back and it's fine to be extremely strict. However, offset retrieving can happen much later. A server could have already forgotten about the previous uploaded body, but still want the upload restarted from 0. In the case that the client cannot supply the bytes, it can always decide to not resume, or perform an explicit cancel.
I am not sure if such a case would actually occur where the server has forgotten parts of the uploaded data but has not forgotten the existence of the upload resource itself, allowing the client to still resume the upload. Do you have an example application? I would have imagined that the upload should be considered as unresumable and failed then. The client could create a new upload if its still has the file data and the application logic allows that. That was my motivation behind enforcing a strict requirement that the upload offset never decreases. The Upload-Offset values should be a guarantee by the server that this amount of data has been saved and won't be lost again. If we don't include such a requirement, it could encourage servers to handle the received data without too much care because they are allowed to decrease the offset again.

Related discussion:
text: 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 <del> 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. </del> <ins> the value to inform the client about the upload progress. </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
Code change:
As discussed in URL, this requires the upload offset to not decrease. The server is not allowed to "forget" data appended to an upload. The benefit is that it allows a client to reduce the amount of data buffered while the upload is ongoing as it receives acknowledgements from the server that data has been stored permanently and will not have to be retransmitted. Closes URL
URL added the requirement that the offset reported in 104 informational responses must not decrease over time. For example, it is not allowed that one 104 response includes and the next includes . For now, this requirement is not mentioned for responses to offset retrieval responses. As NAME mentioned in URL, we should add this rule there as well. Maybe it also makes sense to move this into a more central section of the document, so that we don't have to repeat this rule trice (upload creation, upload appending, and offset retrieval).
Thinking about this a bit more, progress reporting and offset retrieving are different enough that adding this requirement to offset retrieving might not actually make sense. In a single append, it's impossible for progress to go back and it's fine to be extremely strict. However, offset retrieving can happen much later. A server could have already forgotten about the previous uploaded body, but still want the upload restarted from 0. In the case that the client cannot supply the bytes, it can always decide to not resume, or perform an explicit cancel.
I am not sure if such a case would actually occur where the server has forgotten parts of the uploaded data but has not forgotten the existence of the upload resource itself, allowing the client to still resume the upload. Do you have an example application? I would have imagined that the upload should be considered as unresumable and failed then. The client could create a new upload if its still has the file data and the application logic allows that. That was my motivation behind enforcing a strict requirement that the upload offset never decreases. The Upload-Offset values should be a guarantee by the server that this amount of data has been saved and won't be lost again. If we don't include such a requirement, it could encourage servers to handle the received data without too much care because they are allowed to decrease the offset again.

Related discussion:
text: informational responses MUST NOT contain the "Location" header field. They MAY include the "Upload-Offset" header field with the current upload offset as the value to inform the client about the upload <del> progress.  The same restrictions on the "Upload-Offset" header field in informational responses from the upload creation (upload-creation) apply. </del> <ins> progress. </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
Code change:
As discussed in URL, this requires the upload offset to not decrease. The server is not allowed to "forget" data appended to an upload. The benefit is that it allows a client to reduce the amount of data buffered while the upload is ongoing as it receives acknowledgements from the server that data has been stored permanently and will not have to be retransmitted. Closes URL
URL added the requirement that the offset reported in 104 informational responses must not decrease over time. For example, it is not allowed that one 104 response includes and the next includes . For now, this requirement is not mentioned for responses to offset retrieval responses. As NAME mentioned in URL, we should add this rule there as well. Maybe it also makes sense to move this into a more central section of the document, so that we don't have to repeat this rule trice (upload creation, upload appending, and offset retrieval).
Thinking about this a bit more, progress reporting and offset retrieving are different enough that adding this requirement to offset retrieving might not actually make sense. In a single append, it's impossible for progress to go back and it's fine to be extremely strict. However, offset retrieving can happen much later. A server could have already forgotten about the previous uploaded body, but still want the upload restarted from 0. In the case that the client cannot supply the bytes, it can always decide to not resume, or perform an explicit cancel.
I am not sure if such a case would actually occur where the server has forgotten parts of the uploaded data but has not forgotten the existence of the upload resource itself, allowing the client to still resume the upload. Do you have an example application? I would have imagined that the upload should be considered as unresumable and failed then. The client could create a new upload if its still has the file data and the application logic allows that. That was my motivation behind enforcing a strict requirement that the upload offset never decreases. The Upload-Offset values should be a guarantee by the server that this amount of data has been saved and won't be lost again. If we don't include such a requirement, it could encourage servers to handle the received data without too much care because they are allowed to decrease the offset again.

Related discussion:
text: apply the redirection directly in an immediate subsequent upload append (upload-appending). <del> 12. </del> <ins> 13. </ins> A message might have a content coding, indicated by the "Content- Encoding" header field, and/or a transfer coding, indicated by the
Code change:
As discussed in URL, this requires the upload offset to not decrease. The server is not allowed to "forget" data appended to an upload. The benefit is that it allows a client to reduce the amount of data buffered while the upload is ongoing as it receives acknowledgements from the server that data has been stored permanently and will not have to be retransmitted. Closes URL
URL added the requirement that the offset reported in 104 informational responses must not decrease over time. For example, it is not allowed that one 104 response includes and the next includes . For now, this requirement is not mentioned for responses to offset retrieval responses. As NAME mentioned in URL, we should add this rule there as well. Maybe it also makes sense to move this into a more central section of the document, so that we don't have to repeat this rule trice (upload creation, upload appending, and offset retrieval).
Thinking about this a bit more, progress reporting and offset retrieving are different enough that adding this requirement to offset retrieving might not actually make sense. In a single append, it's impossible for progress to go back and it's fine to be extremely strict. However, offset retrieving can happen much later. A server could have already forgotten about the previous uploaded body, but still want the upload restarted from 0. In the case that the client cannot supply the bytes, it can always decide to not resume, or perform an explicit cancel.
I am not sure if such a case would actually occur where the server has forgotten parts of the uploaded data but has not forgotten the existence of the upload resource itself, allowing the client to still resume the upload. Do you have an example application? I would have imagined that the upload should be considered as unresumable and failed then. The client could create a new upload if its still has the file data and the application logic allows that. That was my motivation behind enforcing a strict requirement that the upload offset never decreases. The Upload-Offset values should be a guarantee by the server that this amount of data has been saved and won't be lost again. If we don't include such a requirement, it could encourage servers to handle the received data without too much care because they are allowed to decrease the offset again.

Related discussion:
text: offset is counted after the content's transfer coding is reversed but before the content coding is reversed. <del> 13. </del> <ins> 14. </ins> The integrity of an entire upload or individual upload requests can be verifying using digests from DIGEST-FIELDS.
Code change:
As discussed in URL, this requires the upload offset to not decrease. The server is not allowed to "forget" data appended to an upload. The benefit is that it allows a client to reduce the amount of data buffered while the upload is ongoing as it receives acknowledgements from the server that data has been stored permanently and will not have to be retransmitted. Closes URL
URL added the requirement that the offset reported in 104 informational responses must not decrease over time. For example, it is not allowed that one 104 response includes and the next includes . For now, this requirement is not mentioned for responses to offset retrieval responses. As NAME mentioned in URL, we should add this rule there as well. Maybe it also makes sense to move this into a more central section of the document, so that we don't have to repeat this rule trice (upload creation, upload appending, and offset retrieval).
Thinking about this a bit more, progress reporting and offset retrieving are different enough that adding this requirement to offset retrieving might not actually make sense. In a single append, it's impossible for progress to go back and it's fine to be extremely strict. However, offset retrieving can happen much later. A server could have already forgotten about the previous uploaded body, but still want the upload restarted from 0. In the case that the client cannot supply the bytes, it can always decide to not resume, or perform an explicit cancel.
I am not sure if such a case would actually occur where the server has forgotten parts of the uploaded data but has not forgotten the existence of the upload resource itself, allowing the client to still resume the upload. Do you have an example application? I would have imagined that the upload should be considered as unresumable and failed then. The client could create a new upload if its still has the file data and the application logic allows that. That was my motivation behind enforcing a strict requirement that the upload offset never decreases. The Upload-Offset values should be a guarantee by the server that this amount of data has been saved and won't be lost again. If we don't include such a requirement, it could encourage servers to handle the received data without too much care because they are allowed to decrease the offset again.

Related discussion:
text: resource.  This way, the integrity of an individual request can be protected. <del> 14. </del> <ins> 15. </ins> The server might process the uploaded data and make its results available in another resource during or after the upload.  This
Code change:
As discussed in URL, this requires the upload offset to not decrease. The server is not allowed to "forget" data appended to an upload. The benefit is that it allows a client to reduce the amount of data buffered while the upload is ongoing as it receives acknowledgements from the server that data has been stored permanently and will not have to be retransmitted. Closes URL
URL added the requirement that the offset reported in 104 informational responses must not decrease over time. For example, it is not allowed that one 104 response includes and the next includes . For now, this requirement is not mentioned for responses to offset retrieval responses. As NAME mentioned in URL, we should add this rule there as well. Maybe it also makes sense to move this into a more central section of the document, so that we don't have to repeat this rule trice (upload creation, upload appending, and offset retrieval).
Thinking about this a bit more, progress reporting and offset retrieving are different enough that adding this requirement to offset retrieving might not actually make sense. In a single append, it's impossible for progress to go back and it's fine to be extremely strict. However, offset retrieving can happen much later. A server could have already forgotten about the previous uploaded body, but still want the upload restarted from 0. In the case that the client cannot supply the bytes, it can always decide to not resume, or perform an explicit cancel.
I am not sure if such a case would actually occur where the server has forgotten parts of the uploaded data but has not forgotten the existence of the upload resource itself, allowing the client to still resume the upload. Do you have an example application? I would have imagined that the upload should be considered as unresumable and failed then. The client could create a new upload if its still has the file data and the application logic allows that. That was my motivation behind enforcing a strict requirement that the upload offset never decreases. The Upload-Offset values should be a guarantee by the server that this amount of data has been saved and won't be lost again. If we don't include such a requirement, it could encourage servers to handle the received data without too much care because they are allowed to decrease the offset again.

Related discussion:
text: an upload.  For example, a subsequent resource could allow the client to fetch information extracted from the uploaded data. <del> 15. </del> <ins> 16. </ins> The upload resource URL is the identifier used for modifying the upload.  Without further protection of this URL, an attacker may