jiebi/TextFlow huggingface dataset:
Original text:
For malformed requests, a server MAY send an HTTP response prior to closing or resetting the stream.  Clients MUST NOT accept a malformed <del> response.  Note that these requirements are intended to protect against several types of common attacks against HTTP; they are deliberately strict because being permissive can expose implementations to these vulnerabilities. </del>  8.1.3.

Reviewer comments:
The language doesn't properly acknowledge the possibility that some processing might have been performed before an error is detected. This could use some tweaking.
Proposal here: URL
Seems like a reasonable change.
Seems like a nice clear improvement

Revised text:
For malformed requests, a server MAY send an HTTP response prior to closing or resetting the stream.  Clients MUST NOT accept a malformed  <ins> response. Endpoints that progressively process messages might have performed some processing before identifying a request or response as malformed.  For instance, it might be possible to generate an informational or 404 status code without having received a complete request.  Similarly, intermediaries might forward incomplete messages before detecting errors.  A server MAY generate a final response before receiving an entire request when the response does not depend on the remainder of the request being correct.  A server or intermediary MAY use RST_STREAM -- with a code other than REFUSED_STREAM -- to abort a stream if a malformed request or response is received. These requirements are intended to protect against several types of common attacks against HTTP; they are deliberately strict because being permissive can expose implementations to these vulnerabilities. </ins> 8.1.3.
Original text:
This document establishes a registry for HTTP/2 frame type codes. The "HTTP/2 Frame Type" registry manages an 8-bit space.  The "HTTP/2 <del> Frame Type" registry operates under either of the RFC5226 for values between 0x00 and 0xef, with values between 0xf0 and 0xff being reserved for Experimental Use. </del>  New entries in this registry require the following information:

Reviewer comments:
This is part of the fix for . This part removes the experimental range for frame types and settings. Also updates to use section references to RFC 8126, which replaces RFC 5226.
Nice clean change. No notes.

Revised text:
This document establishes a registry for HTTP/2 frame type codes. The "HTTP/2 Frame Type" registry manages an 8-bit space.  The "HTTP/2  <ins> Frame Type" registry operates under either of the RFC8126 or RFC8126 policies. </ins> New entries in this registry require the following information:
Original text:
This document establishes a registry for HTTP/2 settings.  The "HTTP/2 Settings" registry manages a 16-bit space.  The "HTTP/2 <del> Settings" registry operates under the RFC5226 for values in the range from 0x0000 to 0xefff, with values between and 0xf000 and 0xffff being reserved for Experimental Use. </del>  New registrations are advised to provide the following information:

Reviewer comments:
This is part of the fix for . This part removes the experimental range for frame types and settings. Also updates to use section references to RFC 8126, which replaces RFC 5226.
Nice clean change. No notes.

Revised text:
This document establishes a registry for HTTP/2 settings.  The "HTTP/2 Settings" registry manages a 16-bit space.  The "HTTP/2  <ins> Settings" registry operates under the RFC8126. </ins> New registrations are advised to provide the following information:
Original text:
This document establishes a registry for HTTP/2 error codes.  The "HTTP/2 Error Code" registry manages a 32-bit space.  The "HTTP/2 <del> Error Code" registry operates under the RFC5226. </del>  Registrations for error codes are required to include a description of the error code.  An expert reviewer is advised to examine new

Reviewer comments:
This is part of the fix for . This part removes the experimental range for frame types and settings. Also updates to use section references to RFC 8126, which replaces RFC 5226.
Nice clean change. No notes.

Revised text:
This document establishes a registry for HTTP/2 error codes.  The "HTTP/2 Error Code" registry manages a 32-bit space.  The "HTTP/2  <ins> Error Code" registry operates under the RFC8126. </ins> Registrations for error codes are required to include a description of the error code.  An expert reviewer is advised to examine new
Original text:
If an endpoint detects multiple different errors, it MAY choose to report any one of those errors.  If a frame causes a connection <del> error, that error MUST be reported. </del>  5.4.1.

Reviewer comments:
QUIC includes the following statement: I like this. (No accident. I wrote it.) Should HTTP/2 include a similar statement? We have PROTOCOL_ERROR, which has a definition compatible with this statement, so I guess we're already there on as far as allowing a generic code goes. Any sense in saying it explicitly?
Yeah, I think this is sensible text to include.
Reads clearly, captures the intent.

Revised text:
If an endpoint detects multiple different errors, it MAY choose to report any one of those errors.  If a frame causes a connection  <ins> error, that error MUST be reported.  Additionally, an endpoint MAY use any applicable error code when it detects an error condition; a generic error code (such as PROTOCOL_ERROR or INTERNAL_ERROR) can always be used in place of more specific error codes. </ins> 5.4.1.
Original text:
they can be used by an endpoint to measure latency to their peer. This might have privacy implications in certain scenarios.  11. A string for identifying HTTP/2 is entered into the "Application-

Reviewer comments:
Not sure that this needs a citation.
URL describes how HTTP/2 can be used to remove some network-induced jitter from the timing measurements. If your server has timing side channels, then putting requests that can be compared in the same IP packet ensures that the server receives them at the same time. This doesn't help if timing differences are masked by server queuing, CDNs or load balancers, or response delivery, but it can help reduce measurement noise. Consider documenting this.
I'm reading this as editorial not normative (or at least not changing the wire protocol); seems uncontroversial.
Yeah, I'm not sure what else we can say here. There are risks here, there are not really many mitigations available.

Revised text:
they can be used by an endpoint to measure latency to their peer. This might have privacy implications in certain scenarios. <ins> 10.9. Remote timing attacks extract secrets from servers by observing variations in the time that servers take when processing requests that use secrets.  HTTP/2 enables concurrent request creation and processing, which can give attackers better control over when request processing commences.  Multiple HTTP/2 requests can be included in the same IP packet or TLS record.  HTTP/2 can therefore make remote timing attacks more efficient by eliminating variability in request delivery, leaving only request order and the delivery of responses as sources of timing variability. Ensuring that processing time is not dependent on the value of secrets is the best defense against any form of timing attack. </ins> 11. A string for identifying HTTP/2 is entered into the "Application-
Original text:
ABNF rule in HTTP.  10.4. Pushed responses do not have an explicit request from the client; the

Reviewer comments:
Here is some draft text. In principle we don't need any of this at all: as this text shows, all of the relevant guidance is already present in both semantics and H2. I've elected to throw up some possible text, but if we wanted to say that some or all of it is entirely redundant with existing specifications then I'm happy to do so.
Upgrade, Transfer-Encoding, Content-Length, Connection, and anything listed in Connection MUST NOT be forwarded without modification. See also .
Note that this probably goes in
I have no personal knowledge of this issue, but it came up on the #whatwg IRC channel. URL describes Safari rejecting responses that contain the header field, while other browsers accept it. It'd be good to converge the major clients on a single behavior and, if that's not the behavior currently specified, update the spec to match.
To be clear, that's nginx being spectacularly broken by forwarding the header field. I'd characterise the philosophy of H2 as being strict with errors that endanger the whole connection -- and counts the server asking for an upgrade in a context where it doesn't make sense as qualifying as such. While I'd be surprised if folks wanted to relax the former (the strictness is a net win for H2), the latter might be worth revisiting, not because nginx is broken, but because H1's use of headers for connection-level mechanisms turned out to be so broken. I'm also not sure that aligning all clients to be so permissive is such a great idea; accommodating brokenness like this is a race to the bottom, and while it might be the only practical path when you have to interoperate with a large and extremely diverse pool of existing deployment (HTML), there aren't that many HTTP implementations that can move the needle. Interop might be better served by holding the line and forcing broken servers to address their problems.
Additionally, it seems broken for Apache to send the header when the connection between nginx and Apache is over TLS.
Filed .
Apache treats the effects of sending over TLS as a UA-side bug. :-(
Yeah, this looks bad. The spec is fairly unambiguous about the requirement to ignore Upgrade in one place. But it also prohibits the use of Connection, which implies that you can't use Upgrade. I think that we should fix this, potentially along with . I hope that we are able to convince NAME to change Apache here. There is no value in sending this value.
FYI analysis,

Revised text:
ABNF rule in HTTP. <ins> An intermediary that receives any field that requires removal before forwarding (see HTTP) MUST remove or replace those header fields when forwarding messages.  Additionally, intermediaries should take care when forwarding messages containing Content-Length fields to ensure that the message is malformed.  This ensures that if the message is translated into HTTP/1.1 at any point the framing will be correct. </ins> 10.4. Pushed responses do not have an explicit request from the client; the
Original text:
to distinguish them from decimal literals.  The following terms are used: Finally, the terms "gateway", "intermediary", "proxy", and "tunnel"

Reviewer comments:
I haven't adjusted for vs. until that war is over. Note that I've explicitly added a format for the SETTINGS frame itself, which was missing.
+1 . This would make it easier to write extensions for both h2 and h3. Priorities draft suffers from the mixed presentation format right now.
OK, thanks for doing this NAME I merged this manually after fixing a few things up. From my commit: Use all caps for frame names Add a value for Type in frame definitions Change order of flag descriptions to match order in layout Make Exclusive field of PRIORITY optional Move PING ACK Flag to the right place Add SETTINGS ACK Flag Double-checking FTW. Of course, there's a good chance I also messed something up here. So feel free to check my work also.
I think the language about ordering is a bit weird, but it is clarified somewhat by the hex representations shortly after. I think those hex representations are doing the heavy lifting, as I’m not aware of any issue with interoperability caused by getting the flag indices wrong in practice. Nonetheless, if we’re really worried about it we could just delete “bit n” and replace it with “the x bit”, e.g. delete “bit 0” and replace it with “the bit”.

Revised text:
to distinguish them from decimal literals. <ins> This specification describes binary formats using the convention described in QUIC. </ins> The following terms are used: Finally, the terms "gateway", "intermediary", "proxy", and "tunnel"
Original text:
frames to obscure the size of messages.  Padding is a security feature; see padding. <del> The DATA frame contains the following fields: </del>  The DATA frame defines the following flags:

Reviewer comments:
I haven't adjusted for vs. until that war is over. Note that I've explicitly added a format for the SETTINGS frame itself, which was missing.
+1 . This would make it easier to write extensions for both h2 and h3. Priorities draft suffers from the mixed presentation format right now.
OK, thanks for doing this NAME I merged this manually after fixing a few things up. From my commit: Use all caps for frame names Add a value for Type in frame definitions Change order of flag descriptions to match order in layout Make Exclusive field of PRIORITY optional Move PING ACK Flag to the right place Add SETTINGS ACK Flag Double-checking FTW. Of course, there's a good chance I also messed something up here. So feel free to check my work also.
I think the language about ordering is a bit weird, but it is clarified somewhat by the hex representations shortly after. I think those hex representations are doing the heavy lifting, as I’m not aware of any issue with interoperability caused by getting the flag indices wrong in practice. Nonetheless, if we’re really worried about it we could just delete “bit n” and replace it with “the x bit”, e.g. delete “bit 0” and replace it with “the bit”.

Revised text:
frames to obscure the size of messages.  Padding is a security feature; see padding.  <ins> The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fields are described in FramingLayer.  The DATA frame contains the following additional fields: </ins> The DATA frame defines the following flags:
Original text:
HEADERS frames can be sent on a stream in the "idle", "reserved (local)", "open", or "half-closed (remote)" state. <del> The HEADERS frame payload has the following fields: </del>  The HEADERS frame defines the following flags:

Reviewer comments:
I haven't adjusted for vs. until that war is over. Note that I've explicitly added a format for the SETTINGS frame itself, which was missing.
+1 . This would make it easier to write extensions for both h2 and h3. Priorities draft suffers from the mixed presentation format right now.
OK, thanks for doing this NAME I merged this manually after fixing a few things up. From my commit: Use all caps for frame names Add a value for Type in frame definitions Change order of flag descriptions to match order in layout Make Exclusive field of PRIORITY optional Move PING ACK Flag to the right place Add SETTINGS ACK Flag Double-checking FTW. Of course, there's a good chance I also messed something up here. So feel free to check my work also.
I think the language about ordering is a bit weird, but it is clarified somewhat by the hex representations shortly after. I think those hex representations are doing the heavy lifting, as I’m not aware of any issue with interoperability caused by getting the flag indices wrong in practice. Nonetheless, if we’re really worried about it we could just delete “bit n” and replace it with “the x bit”, e.g. delete “bit 0” and replace it with “the bit”.

Revised text:
HEADERS frames can be sent on a stream in the "idle", "reserved (local)", "open", or "half-closed (remote)" state.  <ins> The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fields are described in FramingLayer.  The HEADERS frame payload has the following additional fields: </ins> The HEADERS frame defines the following flags:
Original text:
PRIORITY frame can be sent in any stream state, including idle or closed streams. <del> The frame payload of a PRIORITY frame contains the following fields: </del>  The PRIORITY frame does not define any flags.

Reviewer comments:
I haven't adjusted for vs. until that war is over. Note that I've explicitly added a format for the SETTINGS frame itself, which was missing.
+1 . This would make it easier to write extensions for both h2 and h3. Priorities draft suffers from the mixed presentation format right now.
OK, thanks for doing this NAME I merged this manually after fixing a few things up. From my commit: Use all caps for frame names Add a value for Type in frame definitions Change order of flag descriptions to match order in layout Make Exclusive field of PRIORITY optional Move PING ACK Flag to the right place Add SETTINGS ACK Flag Double-checking FTW. Of course, there's a good chance I also messed something up here. So feel free to check my work also.
I think the language about ordering is a bit weird, but it is clarified somewhat by the hex representations shortly after. I think those hex representations are doing the heavy lifting, as I’m not aware of any issue with interoperability caused by getting the flag indices wrong in practice. Nonetheless, if we’re really worried about it we could just delete “bit n” and replace it with “the x bit”, e.g. delete “bit 0” and replace it with “the bit”.

Revised text:
PRIORITY frame can be sent in any stream state, including idle or closed streams.  <ins> The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fields are described in FramingLayer.  The frame payload of a PRIORITY frame contains the following additional fields: </ins> The PRIORITY frame does not define any flags.
Original text:
stream.  RST_STREAM is sent to request cancellation of a stream or to indicate that an error condition has occurred. <del> The RST_STREAM frame contains a single unsigned, 32-bit integer identifying the ErrorCodes.  The error code indicates why the stream is being terminated. </del>  The RST_STREAM frame does not define any flags.

Reviewer comments:
I haven't adjusted for vs. until that war is over. Note that I've explicitly added a format for the SETTINGS frame itself, which was missing.
+1 . This would make it easier to write extensions for both h2 and h3. Priorities draft suffers from the mixed presentation format right now.
OK, thanks for doing this NAME I merged this manually after fixing a few things up. From my commit: Use all caps for frame names Add a value for Type in frame definitions Change order of flag descriptions to match order in layout Make Exclusive field of PRIORITY optional Move PING ACK Flag to the right place Add SETTINGS ACK Flag Double-checking FTW. Of course, there's a good chance I also messed something up here. So feel free to check my work also.
I think the language about ordering is a bit weird, but it is clarified somewhat by the hex representations shortly after. I think those hex representations are doing the heavy lifting, as I’m not aware of any issue with interoperability caused by getting the flag indices wrong in practice. Nonetheless, if we’re really worried about it we could just delete “bit n” and replace it with “the x bit”, e.g. delete “bit 0” and replace it with “the bit”.

Revised text:
stream.  RST_STREAM is sent to request cancellation of a stream or to indicate that an error condition has occurred.  <ins> The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fields are described in FramingLayer.  Additionally, the RST_STREAM frame contains a single unsigned, 32-bit integer identifying the ErrorCodes.  The error code indicates why the stream is being terminated. </ins> The RST_STREAM frame does not define any flags.
Original text:
provides additional context for the stream.  PushResources contains a thorough description of the use of PUSH_PROMISE frames. <del> The PUSH_PROMISE frame payload has the following fields: </del>  The PUSH_PROMISE frame defines the following flags:

Reviewer comments:
I haven't adjusted for vs. until that war is over. Note that I've explicitly added a format for the SETTINGS frame itself, which was missing.
+1 . This would make it easier to write extensions for both h2 and h3. Priorities draft suffers from the mixed presentation format right now.
OK, thanks for doing this NAME I merged this manually after fixing a few things up. From my commit: Use all caps for frame names Add a value for Type in frame definitions Change order of flag descriptions to match order in layout Make Exclusive field of PRIORITY optional Move PING ACK Flag to the right place Add SETTINGS ACK Flag Double-checking FTW. Of course, there's a good chance I also messed something up here. So feel free to check my work also.
I think the language about ordering is a bit weird, but it is clarified somewhat by the hex representations shortly after. I think those hex representations are doing the heavy lifting, as I’m not aware of any issue with interoperability caused by getting the flag indices wrong in practice. Nonetheless, if we’re really worried about it we could just delete “bit n” and replace it with “the x bit”, e.g. delete “bit 0” and replace it with “the bit”.

Revised text:
provides additional context for the stream.  PushResources contains a thorough description of the use of PUSH_PROMISE frames.  <ins> The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fields are described in FramingLayer.  The PUSH_PROMISE frame payload has the following additional fields: </ins> The PUSH_PROMISE frame defines the following flags:
Original text:
idle connection is still functional.  PING frames can be sent from any endpoint.  In addition to the frame header, PING frames MUST contain 8 octets of opaque data in the frame payload.  A sender can include any value it chooses and use those octets in any fashion.

Reviewer comments:
I haven't adjusted for vs. until that war is over. Note that I've explicitly added a format for the SETTINGS frame itself, which was missing.
+1 . This would make it easier to write extensions for both h2 and h3. Priorities draft suffers from the mixed presentation format right now.
OK, thanks for doing this NAME I merged this manually after fixing a few things up. From my commit: Use all caps for frame names Add a value for Type in frame definitions Change order of flag descriptions to match order in layout Make Exclusive field of PRIORITY optional Move PING ACK Flag to the right place Add SETTINGS ACK Flag Double-checking FTW. Of course, there's a good chance I also messed something up here. So feel free to check my work also.
I think the language about ordering is a bit weird, but it is clarified somewhat by the hex representations shortly after. I think those hex representations are doing the heavy lifting, as I’m not aware of any issue with interoperability caused by getting the flag indices wrong in practice. Nonetheless, if we’re really worried about it we could just delete “bit n” and replace it with “the x bit”, e.g. delete “bit 0” and replace it with “the bit”.

Revised text:
idle connection is still functional.  PING frames can be sent from any endpoint. <ins> The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fields are described in FramingLayer. </ins> In addition to the frame header, PING frames MUST contain 8 octets of opaque data in the frame payload.  A sender can include any value it chooses and use those octets in any fashion.