jiebi/CodeConvo huggingface dataset:
Code change:
See as an alternative.
Thanks everyone for your patience here. It's good to see this work out :)
Validating fields for characters has raised a concern where we don't have a clear delineation between framing and semantics. So the way that endpoints handle those cases is unclear. For requests in particular, the choice between resetting a stream and sending a 4xx response is unclear. It would be good if we could have more consistent overall behaviour here, but we have seen from the character composition issue (see ) that different implementations will enforce the rules at different layers. We probably need to allow for some flexibility. NAME has volunteered to help us navigate this somewhat nuanced issue.
I think this is reasonable. LGTM

Related discussion:
text: MUST NOT forward fields that contain any of the values that are listed as prohibited above. <del> Field values that are not valid according to the definition of the corresponding field do not cause a request to be malformed except as defined by the processing rules for the field. </del> <ins> A recipient MAY treat a message that contains a field name or value that includes other characters disallowed by HTTP and HTTP as malformed. When a request message violates one of the requirements above, it SHOULD be responded to using the 400 (Bad Request) status code HTTP before the stream is reset, unless a more suitable status code is defined, or the status code cannot be sent (e.g., because the error occurs in a trailer field). Note that field values that are not valid according to the definition of the corresponding field do not cause a request to be malformed; the requirements above only apply to the generic syntax for field values as defined in HTTP. </ins> 8.1.2.1.
Code change:
See as an alternative.
Thanks everyone for your patience here. It's good to see this work out :)
Validating fields for characters has raised a concern where we don't have a clear delineation between framing and semantics. So the way that endpoints handle those cases is unclear. For requests in particular, the choice between resetting a stream and sending a 4xx response is unclear. It would be good if we could have more consistent overall behaviour here, but we have seen from the character composition issue (see ) that different implementations will enforce the rules at different layers. We probably need to allow for some flexibility. NAME has volunteered to help us navigate this somewhat nuanced issue.
I think this is reasonable. LGTM

Related discussion:
text: A malformed request or response is one that is an otherwise valid sequence of HTTP/2 frames but is invalid due to the presence of extraneous frames, prohibited fields or pseudo-header fields, the <del> absence of mandatory fields or pseudo-header fields, or the inclusion of uppercase field names. </del> <ins> absence of mandatory fields or pseudo-header fields, the inclusion of uppercase field names, or invalid field names and/or values (in certain circumstances; see HttpHeaders). </ins> A request or response that includes message content can include a
Code change:
new registry for fields; see
NAME removed upgrade and changed the registration of this header field to: Is that OK? Or would you prefer a complete registration update, as in: Field Name: HTTP2-Settings Status: Standard Ref.: Section 11.5 of RFC 7540 Comments: This field is obsoleted (this document).
That should be fine.

Related discussion:
text: error codes.  These new registries appear in the new "Hypertext Transfer Protocol version 2 (HTTP/2)" section. <del> This document registers the </del> <ins> This revision of the document marks the </ins> <del> header field for use in HTTP. </del> <ins> header field registered in RFC7540 obsolete. </ins> This document registers the
Code change:
new registry for fields; see
NAME removed upgrade and changed the registration of this header field to: Is that OK? Or would you prefer a complete registration update, as in: Field Name: HTTP2-Settings Status: Standard Ref.: Section 11.5 of RFC 7540 Comments: This field is obsoleted (this document).
That should be fine.

Related discussion:
text: This section marks the <del> header field registered in RFC7540 as obsoleted. </del> <ins> header field registered in RFC7540 as obsoleted.  The registration is updated to include the details as required by HTTP: </ins> 11.6.
Code change:
This is a rearrangement of the HTTP-related sections, in preparation for actually addressing 867.
This doesn't actually address the issue -- I came to a point where I realised this would add a bunch of new requirements and prose that would need heavy scrutiny, and if we want to finish soon, that may not be advisable (although maybe we can figure it out during WGLC). In the meantime, I think this rearrangement is much clearer than the original ordering -- see what you think.
The section talks about how to generate the various pseudo-header fields from a message, but not not how to create a message from the abstract constructs in HTTP semantics, such as the target URI. This includes security considerations around trusting the contents of . I'm happy to do a PR for this. Also, this is a weird paragraph: "HTTP/2 shares the same default port numbers" implies that it could choose to do otherwise; while that might have been an open question pre-core, I think this needs to be re-worded. Likewise, "requests for target resource URIs" is odd; is this meant to be "requests with target URIs"?
Yeah, most of this is just OLD. For instance, the "discovery" aspect really only relates to the need to use ALPN, but we have a better nomenclature now. If you are happy to do a PR, I'm more than happy to review rather than write.

Related discussion:
text: 8. <del> HTTP/2 defines a framing of the HTTP message abstraction (HTTP). </del> 8.1. <ins> HTTP/2 defines a framing of the HTTP message abstraction (HTTP). </ins> A client sends an HTTP request on a new stream, using a previously unused StreamIdentifiers.  A server sends an HTTP response on the same stream as the request.
Code change:
This is a rearrangement of the HTTP-related sections, in preparation for actually addressing 867.
This doesn't actually address the issue -- I came to a point where I realised this would add a bunch of new requirements and prose that would need heavy scrutiny, and if we want to finish soon, that may not be advisable (although maybe we can figure it out during WGLC). In the meantime, I think this rearrangement is much clearer than the original ordering -- see what you think.
The section talks about how to generate the various pseudo-header fields from a message, but not not how to create a message from the abstract constructs in HTTP semantics, such as the target URI. This includes security considerations around trusting the contents of . I'm happy to do a PR for this. Also, this is a weird paragraph: "HTTP/2 shares the same default port numbers" implies that it could choose to do otherwise; while that might have been an open question pre-core, I think this needs to be re-worded. Likewise, "requests for target resource URIs" is odd; is this meant to be "requests with target URIs"?
Yeah, most of this is just OLD. For instance, the "discovery" aspect really only relates to the need to use ALPN, but we have a better nomenclature now. If you are happy to do a PR, I'm more than happy to review rather than write.

Related discussion:
text: the requirements above only apply to the generic syntax for field values as defined in HTTP. <del> 8.1.2.1. HTTP/2 uses special pseudo-header fields beginning with ':' character (ASCII 0x3a) to convey message control data (see HTTP). Pseudo-header fields are not HTTP header fields.  Endpoints MUST NOT generate pseudo-header fields other than those defined in this document.  Note that an extension could negotiate the use of additional pseudo-header fields; see extensibility. Pseudo-header fields are only valid in the context in which they are defined.  Pseudo-header fields defined for requests MUST NOT appear in responses; pseudo-header fields defined for responses MUST NOT appear in requests.  Pseudo-header fields MUST NOT appear in a trailer section.  Endpoints MUST treat a request or response that contains undefined or invalid pseudo-header fields as malformed. All pseudo-header fields MUST appear in a field block before all regular field lines.  Any request or response that contains a pseudo- header field that appears in a field block after a regular field line MUST be treated as malformed. 8.1.2.2. </del> <ins> 8.2.2. </ins> HTTP/2 does not use the <del> header field to indicate connection-specific header fields; in this protocol, connection-specific metadata is conveyed by other means. An endpoint MUST NOT generate an HTTP/2 message containing </del> <ins> header field (HTTP) to indicate connection-specific header fields; in this protocol, connection-specific metadata is conveyed by other means.  An endpoint MUST NOT generate an HTTP/2 message containing </ins> connection-specific header fields; any message containing connection- specific header fields MUST be treated as malformed.
Code change:
This is a rearrangement of the HTTP-related sections, in preparation for actually addressing 867.
This doesn't actually address the issue -- I came to a point where I realised this would add a bunch of new requirements and prose that would need heavy scrutiny, and if we want to finish soon, that may not be advisable (although maybe we can figure it out during WGLC). In the meantime, I think this rearrangement is much clearer than the original ordering -- see what you think.
The section talks about how to generate the various pseudo-header fields from a message, but not not how to create a message from the abstract constructs in HTTP semantics, such as the target URI. This includes security considerations around trusting the contents of . I'm happy to do a PR for this. Also, this is a weird paragraph: "HTTP/2 shares the same default port numbers" implies that it could choose to do otherwise; while that might have been an open question pre-core, I think this needs to be re-worded. Likewise, "requests for target resource URIs" is odd; is this meant to be "requests with target URIs"?
Yeah, most of this is just OLD. For instance, the "discovery" aspect really only relates to the need to use ALPN, but we have a better nomenclature now. If you are happy to do a PR, I'm more than happy to review rather than write.

Related discussion:
text: connection-specific header fields as discussed in HTTP, or their messages will be treated by other HTTP/2 endpoints as malformed. <del> 8.1.2.3. The following pseudo-header fields are defined for HTTP/2 requests: All HTTP/2 requests MUST include exactly one valid value for the , , and pseudo-header fields, unless it is a CONNECT.  An HTTP request that omits mandatory pseudo-header fields is malformed. Individual HTTP/2 requests do not carry an explicit indicator of protocol version.  All HTTP/2 messages implicitly have a protocol version of "2.0" (see HTTP). 8.1.2.4. For HTTP/2 responses, a single pseudo-header field is defined that carries the HTTP status code field (see HTTP).  This pseudo-header field MUST be included in all responses, including interim responses; otherwise, the response is malformed. HTTP/2 responses implicitly have a protocol version of "2.0". 8.1.2.5. </del> <ins> 8.2.3. </ins> The COOKIE uses a semi-colon (";") to delimit cookie-pairs (or "crumbs").  This header field contains multiple values, but does not
Code change:
This is a rearrangement of the HTTP-related sections, in preparation for actually addressing 867.
This doesn't actually address the issue -- I came to a point where I realised this would add a bunch of new requirements and prose that would need heavy scrutiny, and if we want to finish soon, that may not be advisable (although maybe we can figure it out during WGLC). In the meantime, I think this rearrangement is much clearer than the original ordering -- see what you think.
The section talks about how to generate the various pseudo-header fields from a message, but not not how to create a message from the abstract constructs in HTTP semantics, such as the target URI. This includes security considerations around trusting the contents of . I'm happy to do a PR for this. Also, this is a weird paragraph: "HTTP/2 shares the same default port numbers" implies that it could choose to do otherwise; while that might have been an open question pre-core, I think this needs to be re-worded. Likewise, "requests for target resource URIs" is odd; is this meant to be "requests with target URIs"?
Yeah, most of this is just OLD. For instance, the "discovery" aspect really only relates to the need to use ALPN, but we have a better nomenclature now. If you are happy to do a PR, I'm more than happy to review rather than write.

Related discussion:
text: PROTOCOL_ERROR.  A server cannot set the SETTINGS_ENABLE_PUSH setting to a value other than 0 (see SettingValues). <del> 8.2.1. </del> <ins> 8.4.1. </ins> Server push is semantically equivalent to a server responding to a request; however, in this case, that request is also sent by the
Code change:
This is a rearrangement of the HTTP-related sections, in preparation for actually addressing 867.
This doesn't actually address the issue -- I came to a point where I realised this would add a bunch of new requirements and prose that would need heavy scrutiny, and if we want to finish soon, that may not be advisable (although maybe we can figure it out during WGLC). In the meantime, I think this rearrangement is much clearer than the original ordering -- see what you think.
The section talks about how to generate the various pseudo-header fields from a message, but not not how to create a message from the abstract constructs in HTTP semantics, such as the target URI. This includes security considerations around trusting the contents of . I'm happy to do a PR for this. Also, this is a weird paragraph: "HTTP/2 shares the same default port numbers" implies that it could choose to do otherwise; while that might have been an open question pre-core, I think this needs to be re-worded. Likewise, "requests for target resource URIs" is odd; is this meant to be "requests with target URIs"?
Yeah, most of this is just OLD. For instance, the "discovery" aspect really only relates to the need to use ALPN, but we have a better nomenclature now. If you are happy to do a PR, I'm more than happy to review rather than write.

Related discussion:
text: into the "reserved (local)" state for the server and the "reserved (remote)" state for the client. <del> 8.2.2. </del> <ins> 8.4.2. </ins> After sending the PUSH_PROMISE frame, the server can begin delivering the pushed response as a HttpResponse on a server-initiated stream
Code change:
This is a rearrangement of the HTTP-related sections, in preparation for actually addressing 867.
This doesn't actually address the issue -- I came to a point where I realised this would add a bunch of new requirements and prose that would need heavy scrutiny, and if we want to finish soon, that may not be advisable (although maybe we can figure it out during WGLC). In the meantime, I think this rearrangement is much clearer than the original ordering -- see what you think.
The section talks about how to generate the various pseudo-header fields from a message, but not not how to create a message from the abstract constructs in HTTP semantics, such as the target URI. This includes security considerations around trusting the contents of . I'm happy to do a PR for this. Also, this is a weird paragraph: "HTTP/2 shares the same default port numbers" implies that it could choose to do otherwise; while that might have been an open question pre-core, I think this needs to be re-worded. Likewise, "requests for target resource URIs" is odd; is this meant to be "requests with target URIs"?
Yeah, most of this is just OLD. For instance, the "discovery" aspect really only relates to the need to use ALPN, but we have a better nomenclature now. If you are happy to do a PR, I'm more than happy to review rather than write.

Related discussion:
text: and ends with a frame bearing END_STREAM, which places the stream in the "closed" state. <del> 8.3. </del> <ins> 8.5. </ins> <del> In HTTP/1.x, the pseudo-method CONNECT (HTTP) is used to convert an HTTP connection into a tunnel to a remote host.  CONNECT is primarily used with HTTP proxies to establish a TLS session with an origin server for the purposes of interacting with </del> <ins> The CONNECT method (HTTP) is used to convert an HTTP connection into a tunnel to a remote host.  CONNECT is primarily used with HTTP proxies to establish a TLS session with an origin server for the purposes of interacting with </ins> resources. <del> In HTTP/2, the CONNECT method is used to establish a tunnel over a single HTTP/2 stream to a remote host for similar purposes.  A CONNECT header section is constructed as defined in HttpRequest ("HttpRequest"), with a few differences.  Specifically: </del> <ins> In HTTP/2, the CONNECT method establishes a tunnel over a single HTTP/2 stream to a remote host, rather than converting the entire connection to a tunnel.  A CONNECT header section is constructed as defined in HttpRequest ("HttpRequest"), with a few differences. Specifically: </ins> A CONNECT request that does not conform to these restrictions is malformed.
Code change:
RFC 4492 is obsolete. This is a TLS 1.2 section, so it is OK to refer to the TLS 1.2 document here.

Related discussion:
text: Implementations MUST support ephemeral key exchange sizes of at least 2048 bits for cipher suites that use ephemeral finite field Diffie- Hellman (DHE) TLS13 and 224 bits for cipher suites that use ephemeral <del> elliptic curve Diffie-Hellman (ECDHE) RFC4492.  Clients MUST accept </del> <ins> elliptic curve Diffie-Hellman (ECDHE) RFC8422.  Clients MUST accept </ins> DHE sizes of up to 4096 bits.  Endpoints MAY treat negotiation of key sizes smaller than the lower limits as a ConnectionErrorHandler of type INADEQUATE_SECURITY.
Code change:
URL is frame formats. I've chosen to put blank lines before and after both frames and the stream identifier part of the stream header. That should make this a lot clearer. NAME was right that this was a little hard to process without that. Hopefully this is a tiny bit better.
I think this helps. The only other clarification I can think of is to pull the flags out into a separate illustration, but let's see if this is sufficient first.
Bah I didn't respond at the right place. One day I'll understand github's interface. Or not :-) Both changes look good and possibly sufficient to me. Let's just wait a bit to see if anyone in the WG has any better proposal. Thanks for your quick reaction!
For the flags (and only the flags), what about trying this:
Should I add the octet values of flags? I would only do that for non-unused flags though.
I believe the prose text contains them, so there's at least a defensible reason for leaving them off.
They're indeed present but not trivially spottable. I have a dead-tree copy of 7540 here with them overlined in pink to spot them faster :-/ We could save a tree by noting them there :-). I agree with Martin that we can avoid the unused ones though, because what matters in tests is not to know the unused ones but rather to figure them as the complement of all known ones. I won't roll over the floor crying if that's rejected, but as an implementer I find that it significantly helps during debugging.
As I don't know how to comment in this format and I don't want to start inventing something (else), I think I'm going to take the coward's option.
What are the semantics of a blank line in this format? /me ducks

Related discussion:
text: to distinguish them from decimal literals. This specification describes binary formats using the convention <del> described in QUIC. </del> <ins> described in QUIC.  Note that this format uses network byte order and high-valued bits are listed before low-valued bits. </ins> The following terms are used:
Code change:
The Priorities section itself has been replaced with a discussion of why priorities aren't there, which is all well and good (). So I found this still being in the introduction a bit odd: If we're talking about the structure of the protocol, I'd think either we don't talk about a feature that's no longer in the protocol, or we explicitly mention it's been cut out.

Related discussion:
text: largely independent of each other, so a blocked or stalled request or response does not prevent progress on other streams. <del> Flow control and prioritization ensure that it is possible to efficiently use multiplexed streams.  FlowControl helps to ensure that only data that can be used by a receiver is transmitted. StreamPriority ensures that limited resources can be directed to the most important streams first. </del> <ins> Effective use of multiplexing depends on flow control and prioritization.  FlowControl ensures that it is possible to efficiently use multiplexed streams by restricting data that is transmitted to what the receiver is able to handle.  StreamPriority ensures that limited resources are used most effectively.  This revision of HTTP/2 deprecates the priority signaling scheme from RFC7540. </ins> Because HTTP fields used in a connection can contain large amounts of redundant data, frames that contain them are FieldBlock.  This has
Code change:
This fixes issue .
I agree on 1 that there's no reason to exclude response pseudo-headers from this requirement. (I was worried about contradicting something regarding multiple interim responses, each of which needs a field, but each of those are in a separate field section, so a rule of no duplicates within a field section should work for pseudo-headers, both request and response.) However, I think that a general prohibition is a good thing. If a future (negotiated) extension wants to introduce a new pseudo-header that can be duplicated, it could override an otherwise general prohibition in this draft. If a future extension doesn't do that, it gets the more sane/safe default for free.
Hmm, yeah, I think I can see a justification for that argument. Given that adding new pseudo-headers needs to be negotiated anyway, I don't think that's a big deal. So I'm happy to go ahead with the change for (1) and skip (2).
NAME is "this" the current text, or revised text to address Cory's comment?
This pull request. I think that a blanket "at most once" is fine and what you have is enough. Future extensions can deal with the consequences of that if they want >1.
NAME Do you want the change to cover responses as well?
That would mean moving it up to the "HTTP Control Data" section. That is a good idea. I missed that this was under requests only.
I moved the language up to the HTTP Control Data section and slightly tweaked it.

Related discussion:
text: header field that appears in a field block after a regular field line MUST be treated as malformed. <ins> The same pseudo-header field name MUST NOT appear more than once in a field block.  A field block for an HTTP request or response that contains a repeated pseudo-header field name MUST be treated as malformed. </ins> 8.3.1. The following pseudo-header fields are defined for HTTP/2 requests:
Code change:
The abstract says This is taken directly from RFC 7540, and seems a bit old hat given where we are at now.
Yeah, probably not needed any more. Propose text?

Related discussion:
text: compression and allowing multiple concurrent exchanges on the same connection. <del> This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax.  HTTP's existing semantics remain unchanged. </del> This document obsoletes RFC 7540 and RFC 8740. Discussion Venues