jiebi/TextFlow huggingface dataset:
Original text:
Clients can send representation metadata (see HTTP) in the request that starts an upload.  Servers MAY interpret this metadata or MAY ignore it.  The "Content-Type" header field (HTTP) can be used to <del> indicate the media type of the file.  The "Content-Disposition" header field (RFC6266) can be used to transmit a filename; if included, the parameters SHOULD be either "filename", "filename*" or "boundary". </del>  4.1.

Reviewer comments:
defines a framework for problem types, which can be used as a standardized response format when errors occurs. With resumable uploads, we have a few cases where such problem types could be useful, but usage remains entirely optional. The text in this PR has been inspired by similar sections from .
Thank you very much for quick feedback, Lucas!

Revised text:
Clients can send representation metadata (see HTTP) in the request that starts an upload.  Servers MAY interpret this metadata or MAY ignore it.  The "Content-Type" header field (HTTP) can be used to  <ins> indicate the media type of the file.  The content coding of the representation is specified using the "Content-Encoding" header field and is retained throughout the entire upload.  When resuming an interrupted upload, the same content coding is used for appending to the upload, producing a representation of the upload resource with one consistent content coding.  The "Content-Disposition" header field (RFC6266) can be used to transmit a filename; if included, the parameters SHOULD be either "filename", "filename*" or "boundary". </ins> 4.1.
Original text:
"Upload-Complete" field value (upload-complete) MUST be set to false. The server SHOULD respect representation metadata received during <del> creation (upload-creation) and ignore any representation metadata received from appending. </del>  If the server does not consider the upload associated with the upload resource active, it MUST respond with a "404 (Not Found)" status

Reviewer comments:
defines a framework for problem types, which can be used as a standardized response format when errors occurs. With resumable uploads, we have a few cases where such problem types could be useful, but usage remains entirely optional. The text in this PR has been inspired by similar sections from .
Thank you very much for quick feedback, Lucas!

Revised text:
"Upload-Complete" field value (upload-complete) MUST be set to false. The server SHOULD respect representation metadata received during  <ins> creation (upload-creation).  An upload append request continues uploading the same representation as used in the upload creation (upload-creation) and thus uses the same content coding, if one was applied.  For example, if the initial upload creation included the "Content-Encoding: gzip" header field, the upload append request resumes the transfer of the gzipped data without indicating again that the gzip coding is applied. </ins> If the server does not consider the upload associated with the upload resource active, it MUST respond with a "404 (Not Found)" status
Original text:
match the offset provided by the immediate previous offset retrieval (offset-retrieving), or the end offset of the immediate previous incomplete successful transfer, the server MUST respond with a "409 <del> (Conflict)" status code. </del>  The server applies the patch document of the "application/partial- upload" media type by appending the request content to the targeted

Reviewer comments:
defines a framework for problem types, which can be used as a standardized response format when errors occurs. With resumable uploads, we have a few cases where such problem types could be useful, but usage remains entirely optional. The text in this PR has been inspired by similar sections from .
Thank you very much for quick feedback, Lucas!

Revised text:
match the offset provided by the immediate previous offset retrieval (offset-retrieving), or the end offset of the immediate previous incomplete successful transfer, the server MUST respond with a "409  <ins> (Conflict)" status code.  The server MAY use the problem type PROBLEM of "https://iana.org/assignments/http-problem-types#mismatching- upload-offset" in the response; see mismatching-offset. </ins> The server applies the patch document of the "application/partial- upload" media type by appending the request content to the targeted
Original text:
10.  The "301 (Moved Permanently)" and "302 (Found)" status codes MUST NOT be used in offset retrieval (offset-retrieving) and upload cancellation (upload-cancellation) responses.  For other responses,

Reviewer comments:
defines a framework for problem types, which can be used as a standardized response format when errors occurs. With resumable uploads, we have a few cases where such problem types could be useful, but usage remains entirely optional. The text in this PR has been inspired by similar sections from .
Thank you very much for quick feedback, Lucas!

Revised text:
10. <ins> 10.1. This section defines the "https://iana.org/assignments/http-problem- types#mismatching-upload-offset" problem type PROBLEM.  A server MAY use this problem type when responding to an upload append request (upload-appending) to indicate that the "Upload-Offset" header field in the request does not match the upload resource's offset. Two problem type extension members are defined: the "expected-offset" and "provided-offset" members.  A response using this problem type SHOULD populate both members, with the value of "expected-offset" taken from the upload resource and the value of "provided-offset" taken from the upload append request. The following example shows an example response, where the resource's offset was 100, but the client attempted to append at offset 200: 10.2. This section defines the "https://iana.org/assignments/http-problem- types#completed-upload" problem type PROBLEM.  A server MAY use this problem type when responding to an upload append request (upload- appending) to indicate that the upload has already been completed and cannot be modified. The following example shows an example response: 11. </ins> The "301 (Moved Permanently)" and "302 (Found)" status codes MUST NOT be used in offset retrieval (offset-retrieving) and upload cancellation (upload-cancellation) responses.  For other responses,
Original text:
apply the redirection directly in an immediate subsequent upload append (upload-appending). <del> 11. </del>  The server might process the uploaded data and make its results available in another resource during or after the upload.  This

Reviewer comments:
defines a framework for problem types, which can be used as a standardized response format when errors occurs. With resumable uploads, we have a few cases where such problem types could be useful, but usage remains entirely optional. The text in this PR has been inspired by similar sections from .
Thank you very much for quick feedback, Lucas!

Revised text:
apply the redirection directly in an immediate subsequent upload append (upload-appending).  <ins> 12. A message might have a content coding, indicated by the "Content- Encoding" header field, and/or a transfer coding, indicated by the "Transfer-Encoding" header field (RFC9112), applied, which modify the representation of uploaded data in a message.  For correct interoperability, the client and server must share the same logic when counting bytes for the upload offset.  From the client's perspective, the offset is counted after content coding but before transfer coding is applied.  From the server's perspective, the offset is counted after the content's transfer coding is reversed but before the content coding is reversed. 13. </ins> The server might process the uploaded data and make its results available in another resource during or after the upload.  This
Original text:
an upload.  For example, a subsequent resource could allow the client to fetch information extracted from the uploaded data. <del> 12. </del>  The upload resource URL is the identifier used for modifying the upload.  Without further protection of this URL, an attacker may

Reviewer comments:
defines a framework for problem types, which can be used as a standardized response format when errors occurs. With resumable uploads, we have a few cases where such problem types could be useful, but usage remains entirely optional. The text in this PR has been inspired by similar sections from .
Thank you very much for quick feedback, Lucas!

Revised text:
an upload.  For example, a subsequent resource could allow the client to fetch information extracted from the uploaded data.  <ins> 14. </ins> The upload resource URL is the identifier used for modifying the upload.  Without further protection of this URL, an attacker may
Original text:
allowed to have, and restricting the length of time an upload resource can exist. <del> 13. </del>  IANA is asked to register the following entries in the "Hypertext Transfer Protocol (HTTP) Field Name Registry":

Reviewer comments:
defines a framework for problem types, which can be used as a standardized response format when errors occurs. With resumable uploads, we have a few cases where such problem types could be useful, but usage remains entirely optional. The text in this PR has been inspired by similar sections from .
Thank you very much for quick feedback, Lucas!

Revised text:
allowed to have, and restricting the length of time an upload resource can exist.  <ins> 15. </ins> IANA is asked to register the following entries in the "Hypertext Transfer Protocol (HTTP) Field Name Registry":
Original text:
Macintosh file type code(s): N/A Windows Clipboard Name: N/A 

Reviewer comments:
defines a framework for problem types, which can be used as a standardized response format when errors occurs. With resumable uploads, we have a few cases where such problem types could be useful, but usage remains entirely optional. The text in this PR has been inspired by similar sections from .
Thank you very much for quick feedback, Lucas!

Revised text:
Macintosh file type code(s): N/A Windows Clipboard Name: N/A <ins> IANA is asked to register the following entry in the "HTTP Problem Types" registry: IANA is asked to register the following entry in the "HTTP Problem Types" registry: </ins>
Original text:
indicated by the "Upload-Offset" field value does not equal the total of begin offset plus the number of bytes uploaded in the request.  If the request completes successfully and the entire upload is complete, the server MUST acknowledge it by responding with a 2xx (Successful) status code.  Servers are RECOMMENDED to use a "201

Reviewer comments:
This is a follow-up to , which defined a problem type for when the server rejects modification for an completed upload. However, the draft didn't specify that such modifications are not allowed. This PR adds this requirement. The section for offset retrieval already includes a definition for when an upload is complete, so this is not repeated in this PR's changes:

Revised text:
indicated by the "Upload-Offset" field value does not equal the total of begin offset plus the number of bytes uploaded in the request. <ins> If the upload is already complete, the server MUST NOT modify the upload resource and MUST respond with a "400 (Bad Request)" status code.  The server MAY use the problem type PROBLEM of "https://iana.org/assignments/http-problem-types#completed-upload" in the response; see completed-upload. </ins> If the request completes successfully and the entire upload is complete, the server MUST acknowledge it by responding with a 2xx (Successful) status code.  Servers are RECOMMENDED to use a "201
Original text:
unnecessary delay in this case, this text is hereby updated as follows:  6. There are now several good examples of designs that prevent the

Reviewer comments:
The draft says there are 4 upgrade tokens, but a fifth one has since been added: connect-ip. It already has text to avoid this issue so it should be a short section.

Revised text:
unnecessary delay in this case, this text is hereby updated as follows: <ins> 5.5. RFC9484 forbids clients from using optimistic upgrade, avoiding this issue. </ins> 6. There are now several good examples of designs that prevent the
Original text:
<del> Security Considerations for Optimistic Use of HTTP Upgrade </del>  draft-ietf-httpbis-optimistic-upgrade-latest Abstract <del> The HTTP/1.1 Upgrade mechanism allows the client to request a change to a new protocol.  This document discusses the security </del>  considerations that apply to data sent by the client before this request is confirmed, and updates RFC 9298 to avoid related security issues.

Reviewer comments:
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

Revised text:
 <ins> Security Considerations for Optimistic Protocol Transitions in HTTP/1.1 </ins> draft-ietf-httpbis-optimistic-upgrade-latest Abstract  <ins> In HTTP/1.1, the client can request a change to a new protocol on the existing connection.  This document discusses the security </ins> considerations that apply to data sent by the client before this request is confirmed, and updates RFC 9298 to avoid related security issues.
Original 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>  <del> This rejection of the upgrade is common, and can happen for a variety of reasons: </del>  The server does not support any of the client's indicated Upgrade Tokens (i.e., the client's proposed new protocols), so it

Reviewer comments:
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

Revised text:
2.  <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>  <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
Original 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>  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>  request issued by the client. 3.2.

Reviewer comments:
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

Revised text:
client and server have distinct interpretations of the data that flows between them.  <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.  <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.
Original 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>  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>  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>  5.

Reviewer comments:
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

Revised 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-  <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  <ins> attacker-controlled, optimistic transmission can cause this </ins> assumption to be violated, exposing vulnerabilities in the server's HTTP request parser. 4.  <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.
Original text:
7.  This document has no IANA actions.

Reviewer comments:
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

Revised 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.
Original text:
4.2. <del> The current interop version is 5. </del>  Client implementations of draft versions of the protocol MUST send a header field "Upload-Draft-Interop-Version" with the interop version

Reviewer comments:
URL made the use of media type mandatory for appending to an upload. This warrants a new interop version.

Revised text:
4.2.  <ins> The current interop version is 6. </ins> Client implementations of draft versions of the protocol MUST send a header field "Upload-Draft-Interop-Version" with the interop version