jiebi/CodeConvo huggingface dataset:
Code change:
the Origin Set (Section 2.3 of ORIGIN) for the connection within which it occurs. <del> Where HTTP/2 reserves Stream 0 for frames related to the state of the connection, HTTP/3 defines a pair of unidirectional streams called "control streams" for this purpose.  Where ORIGIN indicates that the ORIGIN frame should be sent on Stream 0, this should be interpreted to mean the HTTP/3 control stream.  The ORIGIN frame is sent from servers to clients on the server's control stream. The layout and semantics of the frame payload are identical to those of the HTTP/2 frame defined in ORIGIN.  The ORIGIN frame type is 0xc (decimal 12), as in HTTP/2. </del> <ins> The semantics of the frame payload are identical to those of the HTTP/2 frame defined in ORIGIN.  Where HTTP/2 reserves Stream 0 for frames related to the state of the connection, HTTP/3 defines a pair of unidirectional streams called "control streams" for this purpose. Where ORIGIN indicates that the ORIGIN frame should be sent on Stream 0, this should be interpreted to mean the HTTP/3 control stream.  The ORIGIN frame is sent from servers to clients on the server's control stream. 2.1. The ORIGIN frame has a nearly identical layout to that used in HTTP/2, restated here for clarity.  The ORIGIN frame type is 0xc (decimal 12) as in HTTP/2.  The payload contains zero or more instances of the Origin-Entry field. An Origin-Entry is a length-delimited string.  Specifically, it contains two fields: An unsigned, 16-bit integer indicating the length, in octets, of the ASCII-Origin field. An OPTIONAL sequence of characters containing the ASCII serialization of an origin (RFC6454, Section 6.2) that the sender asserts this connection is or could be authoritative for. </ins> 3.

Related discussion:
text: Editorial, since this is merely restating locally what was previously incorporated by reference.
In draft 00 it says: >The layout and semantics of the frame payload are identical to those of the HTTP/2 frame defined in ]. The ORIGIN frame type is 0xc (decimal 12), as in HTTP/2. I think this is the text as it was, before we ran HTTP/3 and HTTP/2 through the process. I think there's some room for editorial improvements to avoid the guesswork. Not least because HTTP/2 Origin has an errata on the payload definition (URL). My suggestion is to just admit defeat and define the whole frame like we do in HTTP/3 or ext priorities, something like Then we can say something like the semantics of the HTTP/3 ORIGIN frame payload are the same as those of the HTTP/2 ORIGIN frame, modulo the differences already described (control streams and whatnot).
Code change:
A gateway that forwards requests that were received in early data MUST only do so if it knows that the server that receives those requests understands the "Early-Data" header field and will correctly <del> generate a 4NN (Too Early) status code.  A gateway that isn't certain </del> <ins> generate a 425 (Too Early) status code.  A gateway that isn't certain </ins> about server support SHOULD either delay forwarding the request until <del> the TLS handshake completes, or send a 4NN (Too Early) status code in </del> <ins> the TLS handshake completes, or send a 425 (Too Early) status code in </ins> response.  A gateway that is uncertain about whether an origin server supports the "Early-Data" header field SHOULD disable early data.

Related discussion:
text: (I accidentally put this on master without noticing earlier, sorry.)
Can we just have 425 now that it's official-ish? From martinthomson/http-replay
Code change:
For example, the following cookies would always be rejected: While the would be accepted if set from a secure origin (e.g. <del> "https://example.com/"), and rejected otherwise: </del> <ins> "https://site.example/"), and rejected otherwise: </ins> 4.2.

Related discussion:
text: This patch replaces with , and corrects inadvertant usage of non-example domains in the hopes of avoiding confusion. Closes httpwg/http-extensions.
NAME mind taking a look?
Landing this. NAME if you object, let me know.
There are still com TLD remaining: and
is real domain. (currently not owned) seems better to use example domain in rfc.
Should we use the .example TLD or stay with URL It's easier to contextualize with .example, in this case webmail.example and projects.example.
SGTM in projects.example, webmail.example etc also URL are fine too.
Code change:
MUST NOT forward fields that contain any of the values that are listed as prohibited above. <del> 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. </del> <ins> When a request message violates one of these requirements, an implementation SHOULD generate a HTTP, 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). </ins> 8.2.2.

Related discussion:
text: I think that should be enough to solve it.
My objection to ABNF is the same as before: we risk that being mistaken as defining what is valid. Something that meets that ABNF is not valid. The point of this section is to define what the absolute minimum is with respect to any form of message handling. Our attempt to require more complete validation roundly failed, so this is where we end up. Willy, I've tried again with the wording. But I want to avoid normative statements regarding the core semantics documents. Those already define what a receiver might do. Those requirements aren't strict enough, at least in the "acting as a tunnel" case, for HTTP/2. The point of this text is to point to HTTP and note that these checks won't guarantee you a valid message, but to allow those implementations that do apply those checks the option of using HTTP/2 signaling (reset streams) to indicate the error condition. I don't think that needs a SHOULD, but I'm OK with adding it.
NAME I think this is a flawed approach. By only defining a subset of invalid fields we create a set of fields that are not valid HTTP but may be valid H2 fields (by merit of being not defined as minimally invalid - just describing it is convoluted). I have yet to see any use-case for a field to be valid in H2 but invalid in HTTP? has identified that the example we have frequently used for such a field (double quote in name) will be a concern if passed onto CGI scripting language. So we have no known uses for such fields and security concerns about at least some of them. So why not just define valid H2 fields as a proper subset of valid HTTP fields plus pseudo fields? We can avoid defining what is valid by referencing other specifications (which do use ABNF). As suggests a field should be valid in H2 if and only if it is: I.e. the set of valid H2 fields is a proper subset of valid HTTP fields plus pseudo fields.
That is what RFC 7540 did. That failed. We can revert all of these changes (aside from editorial tweaks) and go back to what the previous version said, but would that be any more successful?
Code change:
MUST NOT forward fields that contain any of the values that are listed as prohibited above. <del> 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. </del> <ins> When a request message violates one of these requirements, an implementation SHOULD generate a HTTP, 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). </ins> 8.2.2.

Related discussion:
text: There's just one minor thing: It's actually "LF and COLON", but to be exhaustive I'd write "CR, LF, and COLON" since we've always kept extreme care on CR due to older H1 implementations. I think we really want to say something about the pseudo headers. They do not exist in HTTP/1 and the recent portswigger report clearly shows that many of us were relying on the tests performed on the reassembled start line, but that was too late (in my case everything was already NUL/CR/LF clean but LWS were not imagined there). I think it would be appropriate to place the small enumeration I mentioned above somewhere (probably after the "minimal validation" part). But it's possible that it doesn't have its place in the headers section and that it would be better discussed in the security considerations. And maybe then the whole "minimal validation" part can be moved there with it, since after all, it's what all this is about, covering risks that are known for having already been abused. If you're interested I can propose a whole paragraph about all this, as being an implementer makes it easy enough for me to describe the traps. I'm just still having difficulties with all the toolchain and the XML docs which is why I don't send PRs.
(I'll add LF) As for pseudo-headers, welcome back scope creep. Would a simple prohibition on SP (and maybe HTAB) for pseudo-headers work? I'm fairly confident that the substitution is performed as needed, so there are no valid uses for the character. Given that that is the real problem, would that do? I don't feel like a full enumeration is going to be effective, but just one more simple bullet might not hurt.
I've initially thought about it when fixing my bugs ("if I had filtered LWS as well..."). But that's not enough for :scheme nor :path. If :path starts with any character that is valid in a domain name, or a colon, you can change the authority when concatenating values. E.g. or Would result in `URL" or "URL". Similarly if ":scheme" contains a colon, we're lost. In haproxy we've seriously hardened this part so that we don't have to deal with a variant of it any time soon.
Code change:
MUST NOT forward fields that contain any of the values that are listed as prohibited above. <del> 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. </del> <ins> When a request message violates one of these requirements, an implementation SHOULD generate a HTTP, 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). </ins> 8.2.2.

Related discussion:
text: But I think that the absolute bare minimum is: no NUL/CR/LF/LWS in any of the currently known pseudo header fields no colon in :scheme nothing but "/" or "*" as the first char of :path I don't see how to fool a start line parser when reassembling something based on such minimum controls, but I do see how to fool them by relaxing any single one of the rules above.
Editors, it looks like this is ready to ship; anything stopping that?
Only that discussion was continuing. But it seems to have settled now.
Thanks Martin. What about adding the point I made above in URL for :scheme, :path and :method which need further protection (that's not addressed in core since purely H2) ? I could propose this text (yeah I know my formulations are not always great):
HTTP has always forbidden token delimiters in field names. It seems very odd that they are not forbidden in HTTP/2, aside from the specific restriction on colon. The token delimiters are DQUOTE and "(),/:;?NAME We really don't want those allowed in a field name because back-end gateways like CGI assume they have been blocked, and it would mean adding an impossible conversion step when forwarding h2 to h1. Also, it would be easier to read the Field Validity section if it first referenced what is valid for an HTTP field-name, then exclude uppercase because of lowercasing and permit the special-purpose colon for pseudo-fields, and finally list specific requirements on handling invalid characters because the length-delimited protocol elements might be used to carry invalid characters. Likewise, separating the error handling for field-name from that of field-value is useful because they are two different algorithms that are usually implemented separately.
This is really good other than a couple of niggles Expressing it this way makes it really clear the difference between recommended full HTTP validation and the minimal validation that must be imposed if full validation is not done.
Code change:
TLS 1.3 TLS13 introduces the concept of early data (also known as zero round trip data or 0-RTT data).  Early data allows a client to send data to a server in the first round trip of a connection, <del> without waiting for the TLS handshake to complete if the client has </del> <ins> without waiting for the TLS handshake to complete, if the client has </ins> spoken to the same server recently. When used with HTTP HTTP, early data allows clients to send requests

Related discussion:
text: NAME had a few comments in the review of this that are easy to solve.
All changes are OK to me as well. Thanks!
43d2c16 does a great job capturing the point that I made poorly off-list; thanks again!
Code change:
age.calculations. The Age field value is a non-negative integer, representing time in <del> seconds (see delta-seconds).  A cache SHOULD consider a response to be stale if an Age field is present and its value is invalid (i.e., contains a list or something other than a non-negative integer). </del> <ins> seconds (see delta-seconds). Although it is defined as a singleton header field, a cache encountering a message with multiple Age field lines SHOULD use the first field line, discarding subsequent ones. If the field value (after discarding additional lines, as per above) is invalid (e.g., it contains a list or something other than a non- negative integer), a cache SHOULD consider the response to be stale. </ins> The presence of an Age header field implies that the response was not generated or validated by the origin server for this request.

Related discussion:
text: : I think that MAY should be prose, and should also list retrying the request as an option.
Code change:
age.calculations. The Age field value is a non-negative integer, representing time in <del> seconds (see delta-seconds).  A cache SHOULD consider a response to be stale if an Age field is present and its value is invalid (i.e., contains a list or something other than a non-negative integer). </del> <ins> seconds (see delta-seconds). Although it is defined as a singleton header field, a cache encountering a message with multiple Age field lines SHOULD use the first field line, discarding subsequent ones. If the field value (after discarding additional lines, as per above) is invalid (e.g., it contains a list or something other than a non- negative integer), a cache SHOULD consider the response to be stale. </ins> The presence of an Age header field implies that the response was not generated or validated by the origin server for this request.

Related discussion:
text: says: What about multiple ?
I think the right approach here is to require adherence to the most restrictive directive received, but I want to write some more tests first.
OK, the . In a nutshell: No implementation follows the more conservative when multiple are received, either on the same line or separate lines If the directives occur on the same line, most implementations (except Firefox and Apache) prefer the first occurrence. If the directives occur on separate lines, the behaviour is about the same, except that nginx flips and prefers the second line. OTOH most implementations do honour a stricter directive (e.g., or in the presence of more liberal ones like ; the only exceptions there are nuster (a new implementation) and Fastly (this is a known issue). So it seems like the most interoperable thing to do would be to document that when a directive with an argument (like ) appears, the first occurrence should take precedence; however, conflicting directives (like and ) should defer to the strictest.
Code change:
age.calculations. The Age field value is a non-negative integer, representing time in <del> seconds (see delta-seconds).  A cache SHOULD consider a response to be stale if an Age field is present and its value is invalid (i.e., contains a list or something other than a non-negative integer). </del> <ins> seconds (see delta-seconds). Although it is defined as a singleton header field, a cache encountering a message with multiple Age field lines SHOULD use the first field line, discarding subsequent ones. If the field value (after discarding additional lines, as per above) is invalid (e.g., it contains a list or something other than a non- negative integer), a cache SHOULD consider the response to be stale. </ins> The presence of an Age header field implies that the response was not generated or validated by the origin server for this request.

Related discussion:
text: NAME It already is, this just changes how it's done.
My seem to indicate we might want to reconsider how . Of implementations that honour (two don't): none will consider invalid none will consider on two separate field lines invalid none will consider a duplicated value on two lines to make the header invalid if there are two header lines, all will consider only the first (and one, Safari, appears to use the min of them) none considers a non-numeric value to be invalid only Fastly and Firefox consider a non-negative integer to be invalid ... where invalid currently is required to be considered stale.
Code change:
Identify whether the field is a Structured Header (i.e., it can only be used in the header section - the common case), a <del> Structured Field (only in the trailer section), or a Structured </del> <ins> Structured Trailer (only in the trailer section), or a Structured </ins> Field (both). Specify the type of the field value; either List (list),

Related discussion:
text: Editorial: add one reference to Structured Trailers in a list of the types, and correct what appears to be a typo of Structured Field --> Structured Trailer.
Happened to spot these when perusing the structured headers spec; apologies if I've misread and the original text was correct.
Thanks!
Code change:
A large HeaderBlock can cause an implementation to commit a large amount of state.  Header fields that are critical for routing can appear toward the end of a header block, which prevents streaming of <del> header fields to their ultimate destination.  For this an other </del> <ins> header fields to their ultimate destination.  For this and other </ins> reasons, such as ensuring cache correctness, means that an endpoint might need to buffer the entire header block.  Since there is no hard limit to the size of a header block, some endpoints could be forced

Related discussion:
text: Hey so I have a bunch of typos I found and this is one, "an" –> "and" in the "Limits on Header Block Size" section
Code change:
7. <ins> 7.1. To obtain the Status List or Status List Token, the Verifier MUST send a HTTP GET request to the Status List Endpoint.  Communication with the Status List Endpoint MUST utilize TLS.  Which version(s) should be implemented will vary over time.  A TLS server certificate check MUST be performed as defined in Section 5 and 6 of RFC6125. The Verifier SHOULD send the following Accept-Header to indicate the requested response type: "application/statuslist+jwt" for Status List JWTs "application/statuslist+cwt" for Status List CWTs If the Verifier does not send an Accept Header, the reponse type is assumed to be known implicit or out-of-band. 7.2. In the successful response, the Status List Provider MUST use the following content-type: "application/statuslist+jwt" for Status List JWTs "application/statuslist+cwt" for Status List CWTs In the case of "application/statuslist+jwt", the response MUST be of type JWT and follow the rules of jwt-status-list-format-and- processing.  In the case of "application/statuslist+cwt", the response MUST be of type JWT and follow the rules of cwt-status-list- format. The response SHOULD use gzip Content-Encoding as defined in RFC9110. 7.3. If caching is required (e.g., to enable the use of alternative mechanisms for hosting, like Content Delivery Networks), the control of the caching mechanism SHOULD be implemented using the standard HTTP Cache-Control as defined in RFC9111. 7.4. 8. </ins> TBD Define parallel CWT representations for Status Lists and Referenced Tokens.

Related discussion:
text: Defines the HTTP GET API URL
We need to document end to end the validation procedure for a JWT and CWT referencing a status list including resolution of the status list, validation of the status list and how to get the status information for the JWT referencing the status list.
Code change:
When initiating a media session, both the sender and receiver should be able to negotiate the codecs, bitrates and other media details <del> based on capabilities and preferences. </del> <ins> based on capabilities and preferences.  It may be prefered to use existing ecosystem for such purposes, e.g.  SDP RFC4566. </ins> 5.2.

Related discussion:
text: One more use case "Distribution withing a platform" is suggested. It does not seem to be covered by other use cases, but might be worth describing it as well. Some minor suggestions like UDP multicast instead of QUIC as the last mile transport, etc.
Thanks!
Code change:
Append a COMMA to output. <del> Append a single WS to output. </del> <ins> Append a single SP to output. </ins> Return output.

Related discussion:
text: An alternative to - removes HTAB everywhere, replaces with .
Right now we use OWS, and suggests moving from SP to RWS for inner list separation. Should we allow tabs in SH? Error on them? If we want to allow them, 983 makes sense, as it's more consistent. However, we'll need to test for tabs...
What's the reason to allow tabs? Compatibility with current headers? Do actual tab characters show up in the wild that often?
We had them in there because we were reusing OWS, not purposefully. AFAICT they don't appear in the wild much at all. So +1 for .
LGTMThank you for working on this. LGTM.
Code change:
Claim Name: "status_list" Claim Description: A status list containing up-to-date status <del> information on multiple other JWTs encoded as a bitarray. </del> <ins> information on multiple tokens. </ins> Change Controller: IETF

Related discussion:
text: fixes the list rendering (missing newline) clarifies IANA text to just reference other tokens Rendered version: URL
I did further fixes on media types