jiebi/TextFlow huggingface dataset:
Original text:
waiting for the upload to complete before scanning a full file, or disabling resumable uploads.  11. IANA is asked to register the following entries in the "Hypertext

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

Revised 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
Original 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>  An upload is considered complete only if the server completely and successfully received a corresponding creation request (upload-

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

Revised text:
fields by responding with a "400 (Bad Request)" status code. If the server considers the upload resource to be active, it MUST  <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-
Original text:
4.2. <del> The current interop version is 4. </del>  Client implementations of draft versions of the protocol MUST send a header field "Upload-Draft-Interop-Version" with the interop version

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

Revised text:
4.2.  <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
Original 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>  In order to prevent HTTP caching, the response SHOULD include a "Cache-Control" header field with the value "no-store".

Reviewer comments:
There were a few cases of the section linking to itself, which I find distracting, so lets remove them.
Good catch, thank you!

Revised text:
The client MUST NOT start more than one append (upload-appending) based on the resumption offset from a single offset retrieving  <ins> request. </ins> In order to prevent HTTP caching, the response SHOULD include a "Cache-Control" header field with the value "no-store".
Original text:
The server SHOULD respect representation metadata received during creation (upload-creation) and ignore any representation metadata <del> received from appending (upload-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:
There were a few cases of the section linking to itself, which I find distracting, so lets remove them.
Good catch, thank you!

Revised text:
The server SHOULD respect representation metadata received during creation (upload-creation) and ignore any representation metadata  <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
Original 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>  If the offset indicated by the "Upload-Offset" field value does not match the offset provided by the immediate previous offset retrieval

Reviewer comments:
There were a few cases of the section linking to itself, which I find distracting, so lets remove them.
Good catch, thank you!

Revised 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  <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
Original text:
(see output}), and forward it to the upstream HTTP server, then the upstream server performs the validation. <del> The mechanism for the intermediary to communicate this information to the upstream HTTP server is out of scope for this document. </del>  Note that both of these mechanisms require the upstream HTTP server to trust the intermediary.  This is usually the case because the intermediary already needs access to the TLS certificate private key <del> in order to respond to requests. </del>  9.

Reviewer comments:
Please correct me if I'm wrong, but IIUC, the crux of this PR is that to allow any client that can present a valid pair of Authorization and Signature-Auth-Context header fields to obtain a protected resource. Assuming that if we would be allowing such behavior, I wonder why we need to require clients to export keys from TLS session, rather than just coming up with some arbitrary authentication context and present it to the server? Or if it is the case that there are situations in which we have to require clients to use keys exported from TLS session, doesn't it mean that there are cases where servers must ignore Signature-Authentication-Context header field or drop it?
NAME no this is only for trusted intermediaries. If a server receives a Signature-Auth-Context header from an untrusted source then it drops it. That's somewhat mentioned on line 470, but I'll add normative text.

Revised text:
(see output}), and forward it to the upstream HTTP server, then the upstream server performs the validation.  <ins> This document defines the "Signature-Auth-Context" request header field for this latter purpose.  The Signature-Auth-Context header field's value is a Structured Field Byte Sequence (see STRUCTURED- FIELDS) that contains the 48-byte key exporter output (see output), without any parameters.  For example: </ins> Note that both of these mechanisms require the upstream HTTP server to trust the intermediary.  This is usually the case because the intermediary already needs access to the TLS certificate private key  <ins> in order to respond to requests.  HTTP servers that parse the Signature-Auth-Context header field MUST ignore it unless they have already established that they trust the sender. </ins> 9.
Original text:
This document, if approved, requests IANA to register the following entry in the "TLS Exporter Labels" registry maintained at <<https://www.iana.org/assignments/tls-parameters#exporter-labels>>: 

Reviewer comments:
Please correct me if I'm wrong, but IIUC, the crux of this PR is that to allow any client that can present a valid pair of Authorization and Signature-Auth-Context header fields to obtain a protected resource. Assuming that if we would be allowing such behavior, I wonder why we need to require clients to export keys from TLS session, rather than just coming up with some arbitrary authentication context and present it to the server? Or if it is the case that there are situations in which we have to require clients to use keys exported from TLS session, doesn't it mean that there are cases where servers must ignore Signature-Authentication-Context header field or drop it?
NAME no this is only for trusted intermediaries. If a server receives a Signature-Auth-Context header from an untrusted source then it drops it. That's somewhat mentioned on line 470, but I'll add normative text.

Revised text:
This document, if approved, requests IANA to register the following entry in the "TLS Exporter Labels" registry maintained at <<https://www.iana.org/assignments/tls-parameters#exporter-labels>>: <ins> 10.3. This document, if approved, requests IANA to register the following entry in the "Hypertext Transfer Protocol (HTTP) Field Name" registry maintained at <<https://www.iana.org/assignments/http-fields/http- fields.xhtml>>: </ins>
Original text:
2.1.1. The "match" value of the Use-As-Dictionary header is a String value <del> that provides the URLPattern to use for request matching (https://urlpattern.spec.whatwg.org/). </del>  <del> The URLPattern used for matching does not support using Regular </del>  expressions. The following algorithm will return TRUE for a valid match pattern

Reviewer comments:
Changed it to a proper normative reference. For
Merging this. Can always clean it up more if it is still a concern.
For example: Usually, we add something like URLPattern to the references, then that.
Sorry, didn't mean to close the issue. Feel free to close this out if the current language looks OK (also happy to update it if it needs some more tweaking).
Going to close this out now. Thanks for taking the time on this.

Revised text:
2.1.1. The "match" value of the Use-As-Dictionary header is a String value  <ins> that provides the URL Pattern URLPattern to use for request matching. </ins>  <ins> The URL Pattern used for matching does not support using Regular </ins> expressions. The following algorithm will return TRUE for a valid match pattern
Original text:
Let URL be the URL of the dictionary request. <del> Let PATTERN be a URLPattern constructed by setting input=MATCH, and baseURL=URL (https://urlpattern.spec.whatwg.org/). </del>  <del> If PATTERN has regexp groups then return FALSE (https://urlpattern.spec.whatwg.org/#urlpattern-has-regexp- groups). </del>  Return True.

Reviewer comments:
Changed it to a proper normative reference. For
Merging this. Can always clean it up more if it is still a concern.
For example: Usually, we add something like URLPattern to the references, then that.
Sorry, didn't mean to close the issue. Feel free to close this out if the current language looks OK (also happy to update it if it needs some more tweaking).
Going to close this out now. Thanks for taking the time on this.

Revised text:
Let URL be the URL of the dictionary request.  <ins> Let PATTERN be a URL Pattern URLPattern constructed by setting input=MATCH, and baseURL=URL. </ins>  <ins> If PATTERN has regexp groups then return FALSE. </ins> Return True.
Original text:
Let MATCH be the value of "match" for the given dictionary. <del> Let PATTERN be a URLPattern constructed by setting input=MATCH, and baseURL=BASEURL (https://urlpattern.spec.whatwg.org/). </del>  Return the result of running the "test" method of PATTERN with <del> input=URL (https://urlpattern.spec.whatwg.org/#ref-for-dom- urlpattern-test) </del>  2.2.3.

Reviewer comments:
Changed it to a proper normative reference. For
Merging this. Can always clean it up more if it is still a concern.
For example: Usually, we add something like URLPattern to the references, then that.
Sorry, didn't mean to close the issue. Feel free to close this out if the current language looks OK (also happy to update it if it needs some more tweaking).
Going to close this out now. Thanks for taking the time on this.

Revised text:
Let MATCH be the value of "match" for the given dictionary.  <ins> Let PATTERN be a URL Pattern URLPattern constructed by setting input=MATCH, and baseURL=BASEURL. </ins> Return the result of running the "test" method of PATTERN with  <ins> input=URL. </ins> 2.2.3.
Original text:
6.3.1. To make sure that a dictionary can only impact content from the same <del> origin where the dictionary was served, the URLPattern used for matching a dictionary to requests is guaranteed to be for the same origin that the dictionary is served from. </del>  6.3.2.

Reviewer comments:
Changed it to a proper normative reference. For
Merging this. Can always clean it up more if it is still a concern.
For example: Usually, we add something like URLPattern to the references, then that.
Sorry, didn't mean to close the issue. Feel free to close this out if the current language looks OK (also happy to update it if it needs some more tweaking).
Going to close this out now. Thanks for taking the time on this.

Revised text:
6.3.1. To make sure that a dictionary can only impact content from the same  <ins> origin where the dictionary was served, the URL Pattern used for matching a dictionary to requests (match) is guaranteed to be for the same origin that the dictionary is served from. </ins> 6.3.2.
Original text:
3.2. <del> In HTTP/2 and HTTP/3, the client uses the proxy by issuing an "extended CONNECT" request as follows: </del>  The :method pseudo-header field SHALL be "CONNECT".

Reviewer comments:
The CONNECT-TCP draft makes informative references to other drafts which use "extended CONNECT" (CONNECT-UDP, CONNECT-IP), but does not have a normative reference to the draft which defines this use of the CONNECT method. It references the "extended CONNECT" method without supplying a reference for this term. This draft spells out the required values for each pseudo-header, but omits the requirement to set SETTINGSENABLECONNECT_PROTOCOL. A reference to RFCs 8441/9220 is probably needed, and a reminder that the method in this document can only be used if the server sends this setting first.
That'll do.

Revised text:
3.2.  <ins> In HTTP/2 and HTTP/3, the proxy MUST include SETTINGS_ENABLE_CONNECT_PROTOCOL in its SETTINGS frame RFC9220.  The client uses the proxy by issuing an "extended CONNECT" request as follows: </ins> The :method pseudo-header field SHALL be "CONNECT".
Original text:
6.1. <del> The client adds the content encodings that it supports to the "Accept-Encoding" request header. e.g.: </del>  6.2.

Reviewer comments:
Adds language to the to not send the dictionary-aware encodings when a dictionary is not available (or when one is available but not being used). The dictionary-based encodings don't work without a dictionary (they contain a header that has the dictionary hash) and should not be advertised when they are not really available.
Thanks

Revised text:
6.1.  <ins> When a dictionary is available for use on a given request, and the client chooses to make dictionary-based content-encoding available, the client adds the dictionary-aware content encodings that it supports to the "Accept-Encoding" request header. e.g.: When a client does not have a stored dictionary that matches the request, or chooses not to use one for the request, the client MUST NOT send its dictionary-aware content-encodings in the "Accept- Encoding" request header. </ins> 6.2.
Original text:
USASCII character), and WSP (whitespace). The OWS (optional whitespace) and BWS (bad whitespace) rules are <del> defined in Section 5.6.3 of HTTPSEM. </del>  2.3. The terms "user agent", "client", "server", "proxy", and "origin server" have the same meaning as in the HTTP/1.1 specification <del> (HTTPSEM, Section 3). </del>  The request-host is the name of the host, as known by the user agent, to which the user agent is sending an HTTP request or from which it

Reviewer comments:
Updates some out of date portions of the IANA considerations section. See for more info
NAME Ping
NAME Ping
Some aspects of the IANA considerations section are outdated and should be updated: The “Cookie” and “Set-Cookie” registrations from RFC 6265 have been moved from the “Permanent Message Header Field Names” registry to the “HTTP Field Name Registry” Update Sections 9.1 (Cookie) and 9.2 (Set-Cookie)The word "Registry" should be omitted from registry names. Update Section 9.3 (Cookie Attribute Registry)
LGTM. Apologies I missed this.

Revised text:
USASCII character), and WSP (whitespace). The OWS (optional whitespace) and BWS (bad whitespace) rules are  <ins> defined in Section 5.6.3 of RFC9110. </ins> 2.3. The terms "user agent", "client", "server", "proxy", and "origin server" have the same meaning as in the HTTP/1.1 specification  <ins> (RFC9110, Section 3). </ins> The request-host is the name of the host, as known by the user agent, to which the user agent is sending an HTTP request or from which it
Original text:
sent the corresponding HTTP request). The term request-uri refers to "target URI" as defined in Section 7.1 <del> of HTTPSEM. </del>  Two sequences of octets are said to case-insensitively match each other if and only if they are equivalent under the i;ascii-casemap

Reviewer comments:
Updates some out of date portions of the IANA considerations section. See for more info
NAME Ping
NAME Ping
Some aspects of the IANA considerations section are outdated and should be updated: The “Cookie” and “Set-Cookie” registrations from RFC 6265 have been moved from the “Permanent Message Header Field Names” registry to the “HTTP Field Name Registry” Update Sections 9.1 (Cookie) and 9.2 (Set-Cookie)The word "Registry" should be omitted from registry names. Update Section 9.3 (Cookie Attribute Registry)
LGTM. Apologies I missed this.

Revised text:
sent the corresponding HTTP request). The term request-uri refers to "target URI" as defined in Section 7.1  <ins> of RFC9110. </ins> Two sequences of octets are said to case-insensitively match each other if and only if they are equivalent under the i;ascii-casemap
Original text:
RFC6454. "Safe" HTTP methods include "GET", "HEAD", "OPTIONS", and "TRACE", as <del> defined in Section 9.2.1 of HTTPSEM. </del>  A domain's "public suffix" is the portion of a domain that is controlled by a public registry, such as "com", "co.uk", and

Reviewer comments:
Updates some out of date portions of the IANA considerations section. See for more info
NAME Ping
NAME Ping
Some aspects of the IANA considerations section are outdated and should be updated: The “Cookie” and “Set-Cookie” registrations from RFC 6265 have been moved from the “Permanent Message Header Field Names” registry to the “HTTP Field Name Registry” Update Sections 9.1 (Cookie) and 9.2 (Set-Cookie)The word "Registry" should be omitted from registry names. Update Section 9.3 (Cookie Attribute Registry)
LGTM. Apologies I missed this.

Revised text:
RFC6454. "Safe" HTTP methods include "GET", "HEAD", "OPTIONS", and "TRACE", as  <ins> defined in Section 9.2.1 of RFC9110. </ins> A domain's "public suffix" is the portion of a domain that is controlled by a public registry, such as "com", "co.uk", and
Original text:
Origin servers SHOULD NOT fold multiple Set-Cookie header fields into a single header field.  The usual mechanism for folding HTTP headers <del> fields (i.e., as defined in Section 5.3 of HTTPSEM) might change the </del>  semantics of the Set-Cookie header field because the %x2C (",") character is used by Set-Cookie in a way that conflicts with such folding.

Reviewer comments:
Updates some out of date portions of the IANA considerations section. See for more info
NAME Ping
NAME Ping
Some aspects of the IANA considerations section are outdated and should be updated: The “Cookie” and “Set-Cookie” registrations from RFC 6265 have been moved from the “Permanent Message Header Field Names” registry to the “HTTP Field Name Registry” Update Sections 9.1 (Cookie) and 9.2 (Set-Cookie)The word "Registry" should be omitted from registry names. Update Section 9.3 (Cookie Attribute Registry)
LGTM. Apologies I missed this.

Revised text:
Origin servers SHOULD NOT fold multiple Set-Cookie header fields into a single header field.  The usual mechanism for folding HTTP headers  <ins> fields (i.e., as defined in Section 5.3 of RFC9110) might change the </ins> semantics of the Set-Cookie header field because the %x2C (",") character is used by Set-Cookie in a way that conflicts with such folding.