jiebi/CodeConvo huggingface dataset:
Code change:
to use the new "validator" name. See: URL URL
NAME I'm quite weak on that side: is this PR correct? If not feel free to fix at will :)
NAME I agree... this comes from the original RFC 3230. Merging the change as a simple terminology update. The relation b/w validators and the resource is discussed in , where I tagged you as your guidance will be great. See too.
to clarify the following passage for defining the behavior of digest with caching (eg. when Digest is returned together with Last-Modified and ETag). and to better extend the definition of Digest to POST and PATCH requests. This is because though only when they include explicit freshness information. If we go on the new http-core definition (which is cleaner) we have that eg. According to URL POST responses identify returned resources in different ways according to the following: the primary resource is identified by Content-Location the enclosed representation matches the primary resource eg. 1 eg. 2 primary resource identified by enclosed representation matches the status of the request according to the resource's own semantic eg.
re-reading the old RFC my understanding is that validator fields should just be aligned with Digest (that is: digest-value should be aligned with the values of last-modified and etag). While it is trivial, the original editor could have considered that a potential issue.
The change itself looks right. I wonder however about the whole paragraph: what does it mean to say "resource is specified"? Doesn't that also need request header fields upon which the returned representation varies?

Related discussion:
text: or not at all contained in the message body. <del> The resource is specified by the effective request URI and any cache- validator contained in the message. </del> <ins> The resource is specified by the effective request URI and any "validator" contained in the message. </ins> For example, in a response to a HEAD request, the digest is calculated using the representation data that would have been
Code change:
Rationale for 503 is that the service is unavailable due to too many connections. 429 could potentially be an option as well, but that seems more specific to a single user hitting a rate limit, while seems more related to a global limit. /cc NAME NAME

Related discussion:
text: Extra Parameters: None. <del> Recommended HTTP status code: </del> <ins> Recommended HTTP status code: 503 </ins> 3.13.
Code change:
Replaces the old with from URL The relations of Last-Modified and ETag with Digest are examined in

Related discussion:
text: RFC7230. The definitions "representation", "selected representation", <del> "representation data", "representation metadata" and "payload body" </del> <ins> "representation data", "representation metadata", and "payload body" </ins> in this document are to be interpreted as described in RFC7230 and RFC7231. <ins> The definition "validator" in this document is to be interpreted as described in Section 7.2 of RFC7231. </ins> 2. To avoid inconsistencies, an integrity mechanism for HTTP messages
Code change:
Replaces the old with from URL The relations of Last-Modified and ETag with Digest are examined in

Related discussion:
text: or not at all contained in the message body. <del> The resource is specified by the effective request URI and any cache- validator contained in the message. </del> <ins> The resource is specified by the effective request URI and any "validator" contained in the message. </ins> For example, in a response to a HEAD request, the digest is calculated using the representation data that would have been
Code change:
Clarifies the "returned value" expression.
There are two occurences of the fragment This is not the most helpful of statements, when we say "returned value" what exactly are we trying to convey. I think it would help to be a bit more exact.
Thanks. Longer term, I'd like to do an broad editorial sweep to tighten up document and this is an enabling step that I think this takes us most of the way there. I made some suggestions to move words around a bit.

Related discussion:
text: calculated using the representation data that would have been enclosed in the payload body if the same request had been a GET. <del> Digest can be used in requests too.  Returned value depends on the representation metadata header fields. </del> <ins> Digest can be used in requests too. The "Digest" value depends on the representation metadata. </ins> A Digest header field MAY contain multiple representation-data-digest values.  This could be useful for responses expected to reside in
Code change:
Clarifies the "returned value" expression.
There are two occurences of the fragment This is not the most helpful of statements, when we say "returned value" what exactly are we trying to convey. I think it would help to be a bit more exact.
Thanks. Longer term, I'd like to do an broad editorial sweep to tighten up document and this is an enabling step that I think this takes us most of the way there. I made some suggestions to move words around a bit.

Related discussion:
text: 9.4. <del> Digest can be used in requests too.  Returned value depends on the representation metadata header fields. </del> <ins> The request contains a "Digest" header calculated on the enclosed representation. It also includes an "Accept-Encoding: br" header field that advertises the client supports brotli encoding. The response includes a "Content-Encoding: br" that indicates the selected representation is brotli encoded.  The "Digest" field-value is therefore different compared to the request. </ins> Request:
Code change:
An alternate can send an Alt-Svc field that overrides that sent by the origin and is cached on an equal basis.

Related discussion:
text: service can be used for establishing new connections, not limiting the use of existing ones. <ins> Alternative services are fully authoritative for the origin in question, including the ability to clear or update cached alternative service entries, extend freshness lifetimes, and any other authority the origin server would have. </ins> When alternative services are used to send a client to the most optimal server, a change in network configuration can result in cached values becoming suboptimal.  Therefore, clients
Code change:
For . Note that this makes missing values ; if we like that approach, I think we should do it for missing parameter values too (currently they use , which isn't part of our type system). I used because it aligns with the semantics of current uses nicely.
OK with me.
NAME This is a keen observation. Assuming that we are fine with requiring that knowledge on what the top type is, maybe we should also consider adding support for rule. It has been my understanding that the only reason we do not support rule in SH is because can only be applied for certain top types (but we are now requiring that knowledge).
We've discussed requiring knowledge of top-level types extensively, and I think we have agreement that it's OK. I"m not sure what you want regarding support for ; can you give an example (or open a new issue)?
I'm running my SH implementation against the HTTP Archive dumps (400,000,000+ HTTP requests) to see how the from BSH parse in something like the real world. A number of headers are failing because they have valueless dictionary members; e.g., , , . It should be pretty easy to accommodate these, as we already have optional values on parameters.
PTAL at the PR, especially the note about using True for missing parameter values.
Ping NAME NAME
Seems like a reasonable change. I'm happy to remove the 'null' from parameters too.
(already OK'ed in the PR)

Related discussion:
text: 3.2. Dictionaries are ordered maps of name-value pairs, where the names <del> are short, textual strings and the values are items (item) or arrays of items, both of which can be parameterised (param).  There can be zero or more members, and their names are required to be unique within the scope of the dictionary they occur within. </del> <ins> are short, textual strings and the values can be items (item) or arrays of items, both of which can be parameterised (param).  There can be zero or more members, and their names are required to be unique within the scope of the dictionary they occur within. </ins> Implementations MUST provide access to dictionaries both by index and by name.  Specifications MAY use either means of accessing the
Code change:
For . Note that this makes missing values ; if we like that approach, I think we should do it for missing parameter values too (currently they use , which isn't part of our type system). I used because it aligns with the semantics of current uses nicely.
OK with me.
NAME This is a keen observation. Assuming that we are fine with requiring that knowledge on what the top type is, maybe we should also consider adding support for rule. It has been my understanding that the only reason we do not support rule in SH is because can only be applied for certain top types (but we are now requiring that knowledge).
We've discussed requiring knowledge of top-level types extensively, and I think we have agreement that it's OK. I"m not sure what you want regarding support for ; can you give an example (or open a new issue)?
I'm running my SH implementation against the HTTP Archive dumps (400,000,000+ HTTP requests) to see how the from BSH parse in something like the real world. A number of headers are failing because they have valueless dictionary members; e.g., , , . It should be pretty easy to accommodate these, as we already have optional values on parameters.
PTAL at the PR, especially the note about using True for missing parameter values.
Ping NAME NAME
Seems like a reasonable change. I'm happy to remove the 'null' from parameters too.
(already OK'ed in the PR)

Related discussion:
text: whitespace, while names and values are separated by "=" (without whitespace).  For example: <ins> Members whose value is Boolean true MUST omit that value when serialised, unless it has parameters.  For example, here both "b" and "c" are true, but "c"'s value is serialised because it has parameters: Note that this requirement is only on serialisation; parsers are still required to correctly handle the true value when it appears in dictionary values. </ins> A dictionary with a member whose value is an inner-list of tokens: A dictionary with a mix of singular and list values, some with
Code change:
For . Note that this makes missing values ; if we like that approach, I think we should do it for missing parameter values too (currently they use , which isn't part of our type system). I used because it aligns with the semantics of current uses nicely.
OK with me.
NAME This is a keen observation. Assuming that we are fine with requiring that knowledge on what the top type is, maybe we should also consider adding support for rule. It has been my understanding that the only reason we do not support rule in SH is because can only be applied for certain top types (but we are now requiring that knowledge).
We've discussed requiring knowledge of top-level types extensively, and I think we have agreement that it's OK. I"m not sure what you want regarding support for ; can you give an example (or open a new issue)?
I'm running my SH implementation against the HTTP Archive dumps (400,000,000+ HTTP requests) to see how the from BSH parse in something like the real world. A number of headers are failing because they have valueless dictionary members; e.g., , , . It should be pretty easy to accommodate these, as we already have optional values on parameters.
PTAL at the PR, especially the note about using True for missing parameter values.
Ping NAME NAME
Seems like a reasonable change. I'm happy to remove the 'null' from parameters too.
(already OK'ed in the PR)

Related discussion:
text: Append the result of running Serializing a Key (ser-key) with member's member_name to output. <del> Append "=" to output. </del> <ins> If member_value is not Boolean true or parameters is not empty: </ins> <del> If member_value is an array, append the result of running Serialising an Inner List (ser-innerlist) with (member_value, parameters) to output. </del> <ins> Append "=" to output. </ins> <del> Otherwise, append the result of running Serializing an Item (ser-item) with (member_value, parameters) to output. </del> <ins> If member_value is an array, append the result of running Serialising an Inner List (ser-innerlist) with (member_value, parameters) to output. Otherwise, append the result of running Serializing an Item (ser-item) with (member_value, parameters) to output. </ins> If more members remain in input_dictionary:
Code change:
For . Note that this makes missing values ; if we like that approach, I think we should do it for missing parameter values too (currently they use , which isn't part of our type system). I used because it aligns with the semantics of current uses nicely.
OK with me.
NAME This is a keen observation. Assuming that we are fine with requiring that knowledge on what the top type is, maybe we should also consider adding support for rule. It has been my understanding that the only reason we do not support rule in SH is because can only be applied for certain top types (but we are now requiring that knowledge).
We've discussed requiring knowledge of top-level types extensively, and I think we have agreement that it's OK. I"m not sure what you want regarding support for ; can you give an example (or open a new issue)?
I'm running my SH implementation against the HTTP Archive dumps (400,000,000+ HTTP requests) to see how the from BSH parse in something like the real world. A number of headers are failing because they have valueless dictionary members; e.g., , , . It should be pretty easy to accommodate these, as we already have optional values on parameters.
PTAL at the PR, especially the note about using True for missing parameter values.
Ping NAME NAME
Seems like a reasonable change. I'm happy to remove the 'null' from parameters too.
(already OK'ed in the PR)

Related discussion:
text: If dictionary already contains the name this_key, there is a duplicate; fail parsing. <del> Consume the first character of input_string; if it is not "=", fail parsing. </del> <ins> If the first character of input_string is "=": Consume the first character of input_string. Let member be the result of running Parsing an Item or Inner List (parse-item-or-list) with input_string. Otherwise: Let value be Boolean true. Let parameters be an empty, ordered map. </ins> <del> Let member be the result of running Parsing an Item or Inner List (parse-item-or-list) with input_string. </del> <ins> Let member be the tuple (value, parameters). </ins> Add name this_key with value member to dictionary.
Code change:
I'm really not sure what happened there, but don't have time to investigate. I suspect GitHub didn't actually merge.

Related discussion:
text: whitespace, while names and values are separated by "=" (without whitespace).  For example: <ins> Members whose value is Boolean true MUST omit that value when serialised, unless it has parameters.  For example, here both "b" and "c" are true, but "c"'s value is serialised because it has parameters: Note that this requirement is only on serialisation; parsers are still required to correctly handle the true value when it appears in dictionary values. </ins> A dictionary with a member whose value is an inner-list of tokens: A dictionary with a mix of singular and list values, some with
Code change:
I'm really not sure what happened there, but don't have time to investigate. I suspect GitHub didn't actually merge.

Related discussion:
text: Append the result of running Serializing a Key (ser-key) with member's member_name to output. <ins> If member_value is not Boolean true or parameters is not empty: </ins> Append "=" to output. <del> If member_value is an array, append the result of running Serialising an Inner List (ser-innerlist) with (member_value, parameters) to output. </del> <ins> If member_value is an array, append the result of running Serialising an Inner List (ser-innerlist) with (member_value, parameters) to output. </ins> <del> Otherwise, append the result of running Serializing an Item (ser-item) with (member_value, parameters) to output. </del> <ins> Otherwise, append the result of running Serializing an Item (ser-item) with (member_value, parameters) to output. </ins> <del> If more members remain in input_dictionary: </del> <ins> If more members remain in input_dictionary: </ins> <del> Append a COMMA to output. </del> <ins> Append a COMMA to output. </ins> <del> Append a single WS to output. </del> <ins> Append a single WS to output. </ins> Return output.
Code change:
I'm really not sure what happened there, but don't have time to investigate. I suspect GitHub didn't actually merge.

Related discussion:
text: If dictionary already contains the name this_key, there is a duplicate; fail parsing. <del> Consume the first character of input_string; if it is not "=", fail parsing. </del> <ins> If the first character of input_string is "=": Consume the first character of input_string. Let member be the result of running Parsing an Item or Inner List (parse-item-or-list) with input_string. Otherwise: Let value be Boolean true. Let parameters be an empty, ordered map. </ins> <del> Let member be the result of running Parsing an Item or Inner List (parse-item-or-list) with input_string. </del> <ins> Let member be the tuple (value, parameters). </ins> Add name this_key with value member to dictionary.
Code change:
As they relate to changes in SETTINGSHEADERTABLE_SIZE. This is the strict, by-the-book interpretation. That is, if the value changes, you have to send the update, even if it is pointless (that is, you aren't changing the size of the table). Note that I'm eliding the point about multiple instructions, which are necessary if the decoder reduces the maximum below the current size. The only nod in that direction is "at least one" and a reference to the section that talks about the need for multiple updates. This pulls in more of RFC 7541 than I might have liked, but we have to deal with the integration somewhere and this seems like a reasonable place to do that. It might have been better to put this text in a -bis revision of RFC 7541, but we decided to leave that document as-is.
LGTM, this is a nice clarification that removes the possibility of a different interpretation that's known to have caused interoperability issues (nghttp2 vs haproxy). Let's merge it!
Oh I see this PR already being merged. Opened .
I think this PR is in the correct direction. Endpoints have to process instructions using dynamic table, even when they advertise SETTINGSMAXHEADERLISTSIZE of zero. That is because the default is 4096. We did fix this problem in QPACK, but HPACK had already shipped. OTOH, I have concerns regarding new text suggesting Dynamic Table Update Size be sent even when there is no change in the size.I agree with Willy, this is a really good clarification.

Related discussion:
text: A complete field section consists of either: <del> Field compression is stateful.  One compression context and one decompression context are used for the entire connection.  A decoding error in a field block MUST be treated as a ConnectionErrorHandler of type COMPRESSION_ERROR. </del> Each field block is processed as a discrete unit.  Field blocks MUST be transmitted as a contiguous sequence of frames, with no interleaved frames of any other type or from any other stream.  The
Code change:
It's going to happen anyway, but we can at least warn people. This doesn't specify what validation is necessary in any detail (that is somewhat involved), it only notes that simple concatenation is almost certainly not secure.
OK that's fine by me. At least they're warned, and those who want to know more will easily find info on the subject, including these conversations. Thank you Martin!
Before we definitely forget about it, could we please have a consideration for that one: URL There is nothing in H2 that prevents pseudo headers from being abused, and it's suggested that they have to be reassembled to make the whole request line, that is usually parsed later to extract the relevant parts, leading to the trouble reported in the portswigger article. And semantics only apply to the recomposed parts, which is too late. I would really like that we suggest controls there so that future implementations do not get caught by this uncovered area, and the comment above proposes the minimalist controls that protect against such attacks.
Willy, this document is now through IESG evaluation and is about to go to the RFC Editor. Adding substantial new text with requirements would require going back to the working group.
Sorry for letting that comment pass at the time NAME It's a reasonable request, but I don't think that we can go as far as specifying specific validation rules. URIs are just too complicated for that. I suggest that we add a special note to which already talks about how intermediaries might be forced to pass on bad stuff. See .
NAME I understand and your approach looks reasonable, many thanks! I've added a tiny comment so that we don't forget to mention ":method" that was also severely abused there, and it's OK for me. NAME I'm not trying to perform substantial changes but have been trying to reload that one over the last 6 months so that we don't miss it. It has been the main cause of generalized vulnerabilities coming from word-for-word implementation of the spec into code, the least we can do is warn implementers.
LGTM.

Related discussion:
text: delimiters could be used to cause recipients to incorrectly interpret a message, which could be exploited by an attacker. <ins> HttpHeaders does not include specific rules for validation of pseudo- header fields.  If the values of these fields are used, additional validation is necessary.  This is particularly important where , , and are combined to form a single URI string (RFC3986).  Similar problems might occur when that URI or just are combined with to construct a request line (as in HTTP11).  Simple concatenation is not secure unless the input values are fully validated. </ins> An intermediary can reject fields that contain invalid field names or values for other reasons, in particular those that do not conform to the HTTP ABNF grammar from HTTP.  Intermediaries that do not perform
Code change:
Not "of the HTTP protocol".
and 9: To avoid the appearance of "of the Hypertext Transfer Protocol protocol", should these two instances of "of the HTTP protocol" be "of HTTP" (or perhaps, in the case of , "HTTP attributes" instead of "attributes of the HTTP protocol")? Original: The frame and stream layers are tailored to the needs of the HTTP protocol. ... This section outlines attributes of the HTTP protocol that improve interoperability, reduce exposure to known security vulnerabilities, or reduce the potential for implementation variation.
Yeah, "of HTTP" is probably best here.

Related discussion:
text: While some of the frame and stream layer concepts are isolated from HTTP, this specification does not define a completely generic frame <del> layer.  The frame and stream layers are tailored to the needs of the HTTP protocol. </del> <ins> layer.  The frame and stream layers are tailored to the needs of HTTP. </ins> 2.2.
Code change:
Not "of the HTTP protocol".
and 9: To avoid the appearance of "of the Hypertext Transfer Protocol protocol", should these two instances of "of the HTTP protocol" be "of HTTP" (or perhaps, in the case of , "HTTP attributes" instead of "attributes of the HTTP protocol")? Original: The frame and stream layers are tailored to the needs of the HTTP protocol. ... This section outlines attributes of the HTTP protocol that improve interoperability, reduce exposure to known security vulnerabilities, or reduce the potential for implementation variation.
Yeah, "of HTTP" is probably best here.

Related discussion:
text: 9. <del> This section outlines attributes of the HTTP protocol that improve </del> <ins> This section outlines attributes of HTTP that improve </ins> interoperability, reduce exposure to known security vulnerabilities, or reduce the potential for implementation variation.