jiebi/CodeConvo huggingface dataset:
Code change:
As discussed on the mailing list.
:+1:
Make it so that PRIORITY can be sent on a stream in ANY state. i.e., change so that PRIORITY is permitted in the "idle" state.
Discussed in Honolulu; seems reasonable and no objection. Take to list to confirm.

Related discussion:
text: (remote)" or "closed" - state, this frame can only affect processing of the current stream and not frame transmission. <del> The PRIORITY frame is the only frame that can be sent for a stream in the "idle" or "closed" states.  This allows for the reprioritization of a group of dependent streams by altering the priority of an unused or closed parent stream. </del> <ins> The PRIORITY frame can be sent for a stream in the "idle" or "closed" states.  This allows for the reprioritization of a group of dependent streams by altering the priority of an unused or closed parent stream. </ins> A PRIORITY frame with a length other than 5 octets MUST be treated as a StreamErrorHandler of type
Code change:
Proposal for
Taking Mark's base, taking Herve's suggestions and removing some text. I think that this is good.
Folks in the Tor community point out that coalescing connections is a genuinely new vector for tracking users in HTTP/2. This should be pointed out in the Privacy Considerations subsection of Security Considerations, along with mitigations. While we're there, more specific text about mitigating HTTP/2-specific fingerprinting would be nice.
NAME I've marked this as Design, but I think we can prepare a proposal pretty easily. You want to take a crack at it, or should I do a pull?
I'm happy to take input. Since I'm basically offline this week, getting a start would help lots.
Marked as editor-ready; please consider list feedback.

Related discussion:
text: HTTP/2's preference for using a single TCP connection allows correlation of a user's activity on a site.  If connections are reused for different origins, this allows tracking across those <del> origins.  While limited in practicality, this does constitute a new form of tracking. </del> <ins> origins. </ins> Because the PING and SETTINGS frames solicit immediate responses, they can be used by an endpoint to measure latency to their peer.
Code change:
Rather than just PROTOCOLERROR, allow REFUSEDSTREAM. REFUSED_STREAM is a more lenient error. It allows clients to retry requests. Servers might also set the GOAWAY stream number to a lower value if they upgraded.
"5.1.2 Stream Concurrency" says about SETTINGSMAXCONCURRENT_STREAMS: "Endpoints MUST NOT exceed the limit set by their peer. An endpoint that receives a HEADERS frame that causes their advertised concurrent stream limit to be exceeded MUST treat this as a stream error (Section 5.4.2)" But which stream error code should be used? Almost all other references to stream errors in the spec say "treated as a stream error of type XXX"
Also, if this is a stream error, what happens if the client has a CONTINUATION already in flight right behind the current-streams-violating HEADERS frame? The server would then return a stream error to the HEADERS frame, and then see the CONTINUATION frame that's not associated with an in-progress header block. I suppose a server should maintain enough state to remember that it sent a stream error on that stream ID and simply ignore any following CONTINUATION frames instead of returning a connection error?
The server knows that a continuation frame is coming as it is flagged in the HEADERS frame. Regardless, to ensure against corrupting the compression state, even if it is thrown out, all HEADERS/CONTINUATION data must go through the compression context unless you're closing the connection. This is even true for stream IDs that are not in a valid state (though I'd hope in those cases that the receiver would close the connection after immediately sending an error). , Brad Fitzpatrick EMAIL wrote:
NAME good point. My tests don't cover the case of a CONTINUATION having valuable compression context needed for future valid streams. I will update the test suite I'm building.
Discussed on-list; let's go with .

Related discussion:
text: that receives a frame that causes their advertised concurrent stream limit to be <del> exceeded MUST treat this as a StreamErrorHandler.  An endpoint that wishes to reduce the value of </del> <ins> exceeded MUST treat this as a StreamErrorHandler of type or .  An endpoint that wishes to reduce the value of </ins> to a value that is below the current number of open streams can either close streams that exceed the new value or allow streams to
Code change:
Hey so I have a bunch of typos I found and this is one, "an" –> "and" in the "Limits on Header Block Size" section

Related discussion:
text: 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
Code change:
New safe methods can be defined. Does this mean that the client needs to respond with a stream error for methods not known to be safe? See URL
That would be the only logical conclusion. If the client cannot determine if the method is safe, it must assume that it is not.
Indeed. We just need to fix it.

Related discussion:
text: Promised requests MUST be cacheable (see RFC7231), MUST be safe (see RFC7231) and MUST NOT include a request body.  Clients that receive a <del> promised request that is not cacheable, unsafe or that includes a request body MUST reset the stream with a StreamErrorHandler of type </del> <ins> promised request that is not cacheable, is not known to be safe or that indicates the presence of a request body MUST reset the promised stream with a StreamErrorHandler of type </ins> <del> . </del> <ins> .  Note this could result in the promised stream being reset if the client does not recognize a newly defined method as being safe. </ins> Pushed responses that are cacheable (see RFC7234) can be stored by the client, if it implements an HTTP cache.  Pushed responses are
Code change:
The latter part is vestigal, from the time when gzip C-E was mandated. Remove it. Here, I'm less concerned.

Related discussion:
text: 10.6. <del> HTTP/2 enables greater use of compression for both header fields (HeaderBlock) and entity bodies.  Compression can allow an attacker to recover secret data when it is compressed in the same context as data under attacker control. </del> <ins> Compression can allow an attacker to recover secret data when it is compressed in the same context as data under attacker control. HTTP/2 enables compression of header fields (HeaderBlock); the following concerns also apply to the use of HTTP compressed content- codings (RFC7231). </ins> There are demonstrable attacks on compression that exploit the characteristics of the web (e.g., BREACH).  The attacker induces
Code change:
The latter part is vestigal, from the time when gzip C-E was mandated. Remove it. Here, I'm less concerned.

Related discussion:
text: unless separate compression dictionaries are used for each source of data.  Compression MUST NOT be used if the source of data cannot be reliably determined.  Generic stream compression, such as that <del> provided by TLS MUST NOT be used with HTTP/2 (TLSUsage). </del> <ins> provided by TLS MUST NOT be used with HTTP/2 (see TLSUsage). </ins> Further considerations regarding the compression of header fields are described in COMPRESSION.
Code change:
Only if it makes sense to do so. It's a perfectly good word that has been spoiled by an unnecessary inclusion in some popular RFC (2119, I think).

Related discussion:
text: streams in a particular order using priority.  Expressing priority is therefore only ever a suggestion. <del> Providing prioritization information is optional, so default values are used if no explicit indicator is provided (pri-default). </del> <ins> Prioritization information can be omitted from messages.  Defaults are used prior to any explicit values being provided (pri-default). </ins> 5.3.1.
Code change:
Only if it makes sense to do so. It's a perfectly good word that has been spoiled by an unnecessary inclusion in some popular RFC (2119, I think).

Related discussion:
text: 5.3.5. <del> Providing priority information is optional.  Streams are assigned a non-exclusive dependency on stream 0x0 by default.  PushResources initially depend on their associated stream.  In both cases, streams are assigned a default weight of 16. </del> <ins> All streams are initially assigned a non-exclusive dependency on stream 0x0.  PushResources initially depend on their associated stream.  In both cases, streams are assigned a default weight of 16. </ins> 5.4.
Code change:
Only if it makes sense to do so. It's a perfectly good word that has been spoiled by an unnecessary inclusion in some popular RFC (2119, I think).

Related discussion:
text: The DATA frame contains the following fields: An 8-bit field containing the length of the frame padding in units <del> of octets.  This field is optional and is only present if the </del> <ins> of octets.  This field is conditional and is only present if the </ins> PADDED flag is set. Application data.  The amount of data is the remainder of the
Code change:
Only if it makes sense to do so. It's a perfectly good word that has been spoiled by an unnecessary inclusion in some popular RFC (2119, I think).

Related discussion:
text: The HEADERS frame changes the connection state as described in HeaderBlock. <del> The HEADERS frame includes optional padding.  Padding fields and flags are identical to those defined for DATA. </del> <ins> The HEADERS frame can include padding.  Padding fields and flags are identical to those defined for DATA. </ins> Prioritization information in a HEADERS frame is logically equivalent to a separate
Code change:
Only if it makes sense to do so. It's a perfectly good word that has been spoiled by an unnecessary inclusion in some popular RFC (2119, I think).

Related discussion:
text: . <del> The PUSH_PROMISE frame includes optional padding.  Padding fields and flags are identical to those defined for DATA. </del> <ins> The PUSH_PROMISE frame can include padding.  Padding fields and flags are identical to those defined for DATA. </ins> 6.7.
Code change:
Only if it makes sense to do so. It's a perfectly good word that has been spoiled by an unnecessary inclusion in some popular RFC (2119, I think).

Related discussion:
text: responses available in order to fully process the response to the original request. <del> Pushing additional message exchanges in this fashion is optional, and is negotiated between individual endpoints.  The </del> <ins> A client can request that server push be disabled, though this is negotiated for each hop independently.  The </ins> setting can be set to 0 to indicate that server push is disabled.
Code change:
Only if it makes sense to do so. It's a perfectly good word that has been spoiled by an unnecessary inclusion in some popular RFC (2119, I think).

Related discussion:
text: to correlate actions of a single client or server over time.  This includes the value of settings, the manner in which flow control windows are managed, the way priorities are allocated to streams, <del> timing of reactions to stimulus, and handling of any optional features. </del> <ins> timing of reactions to stimulus, and handling of any features that are controlled by settings. </ins> As far as this creates observable differences in behavior, they could be used as a basis for fingerprinting a specific client, as defined
Code change:
There seems to be some disagreement about this, but I think that Roy is right. It's not critical how it is registered, since it shouldn't appear in a valid request anywhere, but it meets the criteria.
I really don't think it matters, so I'm fine with it either way. Theoretically, there may be some compat value in having it listed as safe/idempotent since an intermediary may be more likely to let such methods pass. But the time slice in which this registry has existed and HTTP/2 hasn't will be miniscule -- I expect any HTTP/2-unaware intermediary won't look at the registry values either.
To the extent that it matters (i.e., very little, as you point out), I think that the intermediary example weakens the case for safe+idempotent. I really don't want HTTP/2 to pass an intermediary without triggering some deliberate recognition; that has been the source of some very serious bugs in the past.

Related discussion:
text: PRI <del> No </del> <ins> Yes </ins> <del> No </del> <ins> Yes </ins> ConnectionHeader of this document
Code change:
There were lots of small changes as a result of . The only change of note is URL, which adds text on what a receiver should expect and what they are obligated to do for streams in the "half closed (local)" state.

Related discussion:
text: of the Hypertext Transfer Protocol (HTTP).  HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple <del> concurrent messages on the same connection.  It also introduces </del> <ins> concurrent exchanges on the same connection.  It also introduces </ins> unsolicited push of representations from servers to clients. This specification is an alternative to, but does not obsolete, the
Code change:
There were lots of small changes as a result of . The only change of note is URL, which adds text on what a receiver should expect and what they are obligated to do for streams in the "half closed (local)" state.

Related discussion:
text: Because HTTP header fields used in a connection can contain large amounts of redundant data, frames that contain them are HeaderBlock. This has especially advantageous impact upon request sizes in the <del> common case, allowing many requests to be compressed into one TCP packet. </del> <ins> common case, allowing many requests to be compressed into one packet. </ins> 2.1.
Code change:
There were lots of small changes as a result of . The only change of note is URL, which adds text on what a receiver should expect and what they are obligated to do for streams in the "half closed (local)" state.

Related discussion:
text: An error on the individual HTTP/2 stream. <del> Finally, the terms "gateway", "intermediary", "proxy", and "tunnel" are defined in RFC7230. </del> <ins> Finally, the terms "gateway", "intermediary", "proxy", "tunnel", "message body", and "payload body" are defined in RFC7230. </ins> 3.
Code change:
There were lots of small changes as a result of . The only change of note is URL, which adds text on what a receiver should expect and what they are obligated to do for streams in the "half closed (local)" state.

Related discussion:
text: token.  Such an HTTP/1.1 request MUST include exactly one Http2SettingsHeader header field. <del> Requests that contain an entity body MUST be sent in their entirety </del> <ins> Requests that contain an payload body MUST be sent in their entirety </ins> before the client can send HTTP/2 frames.  This means that a large <del> request entity can block the use of the connection until it is completely sent. </del> <ins> request can block the use of the connection until it is completely sent. </ins> If concurrency of an initial request with subsequent requests is important, an OPTIONS request can be used to perform the upgrade to
Code change:
There were lots of small changes as a result of . The only change of note is URL, which adds text on what a receiver should expect and what they are obligated to do for streams in the "half closed (local)" state.

Related discussion:
text: .  Note that <del> can be sent and received in any stream state.  Frame of unknown types are ignored. </del> <ins> can be sent and received in any stream state.  Frames of unknown types are ignored. </ins> An example of the state transitions for an HTTP request/response exchange can be found in HttpSequence.  An example of the state
Code change:
There were lots of small changes as a result of . The only change of note is URL, which adds text on what a receiver should expect and what they are obligated to do for streams in the "half closed (local)" state.

Related discussion:
text: octets associated with a stream.  One or more DATA frames are used, for instance, to carry HTTP request or response payloads. <del> DATA frames MAY also contain arbitrary padding.  Padding can be added to DATA frames to obscure the size of messages. </del> <ins> DATA frames MAY also contain padding.  Padding can be added to DATA frames to obscure the size of messages. </ins> The DATA frame contains the following fields:
Code change:
There were lots of small changes as a result of . The only change of note is URL, which adds text on what a receiver should expect and what they are obligated to do for streams in the "half closed (local)" state.

Related discussion:
text: zero or more <del> frames containing the message payload (see RFC7230), and </del> <ins> frames containing the payload body (see RFC7230), and </ins> optionally, one
Code change:
There were lots of small changes as a result of . The only change of note is URL, which adds text on what a receiver should expect and what they are obligated to do for streams in the "half closed (local)" state.

Related discussion:
text: of mandatory header fields, or the inclusion of uppercase header field names. <del> A request or response that includes an entity body can include a </del> <ins> A request or response that includes an payload body can include a </ins> "content-length" header field.  A request or response is also malformed if the value of a "content-length" header field does not equal the sum of the
Code change:
There were lots of small changes as a result of . The only change of note is URL, which adds text on what a receiver should expect and what they are obligated to do for streams in the "half closed (local)" state.

Related discussion:
text: This section shows HTTP/1.1 requests and responses, with illustrations of equivalent HTTP/2 requests and responses. <del> An HTTP GET request includes request header fields and no body and is therefore transmitted as a single </del> <ins> An HTTP GET request includes request header fields and no payload body and is therefore transmitted as a single </ins> frame, followed by zero or more
Code change:
had a few actionable comments that seemed relatively easy to handle. In the absence of feedback from NAME and NAME I responded. Of note: the introductory text in URL about the choice to make the format inflexible.

Related discussion:
text: 1. In HTTP/1.1 (see RFC7230), header fields are not compressed.  As Web <del> pages have grown to include dozens to hundreds of requests, the </del> <ins> pages have grown to require dozens to hundreds of requests, the </ins> redundant header fields in these requests unnecessarily consume bandwidth, measurably increasing latency.
Code change:
had a few actionable comments that seemed relatively easy to handle. In the absence of feedback from NAME and NAME I responded. Of note: the introductory text in URL about the choice to make the format inflexible.

Related discussion:
text: known security attacks, and which has a bounded memory requirement for use in constrained environments. <ins> The HPACK format is intentionally simple and inflexible.  Both characteristics reduce the risk of interoperability or security issues based by implementation error.  No extensibility mechanisms are defined; changes to the format are only possible by defining a complete replacement. </ins> 1.1. The format defined in this specification treats a list of header
Code change:
had a few actionable comments that seemed relatively easy to handle. In the absence of feedback from NAME and NAME I responded. Of note: the introductory text in URL about the choice to make the format inflexible.

Related discussion:
text: A name-value pair.  Both the name and value are treated as opaque sequences of octets. <del> The dynamic table (see dynamic.table) is a header table used to associate stored header fields to index values.  This table is dynamic and specific to an encoding or decoding context. </del> <ins> The dynamic table (see dynamic.table) is a table that associates stored header fields with index values.  This table is dynamic and specific to an encoding or decoding context. </ins> <del> The static table (see static.table) is a header table used to associate static header fields to index values.  This table is </del> <ins> The static table (see static.table) is a table that statically associates header fields with index values.  This table is </ins> ordered, read-only, always accessible, and may be shared amongst all encoding or decoding contexts.
Code change:
had a few actionable comments that seemed relatively easy to handle. In the absence of feedback from NAME and NAME I responded. Of note: the introductory text in URL about the choice to make the format inflexible.

Related discussion:
text: To decompress header blocks, a decoder only needs to maintain a dynamic table (see dynamic.table) as a decoding context.  No other <del> state is needed. </del> <ins> dynamic state is needed. </ins> When used for bidirectional communication, such as in HTTP, the encoding and decoding dynamic tables maintained by an endpoint are
Code change:
had a few actionable comments that seemed relatively easy to handle. In the absence of feedback from NAME and NAME I responded. Of note: the introductory text in URL about the choice to make the format inflexible.

Related discussion:
text: original header list. Once a header field is decoded and added to the reconstructed header <del> list, it cannot be removed from it.  A header field added to the </del> <ins> list, the field cannot be removed.  A header field added to the </ins> header list can be safely passed to the application. By passing the resulting header fields to the application, a decoder
Code change:
had a few actionable comments that seemed relatively easy to handle. In the absence of feedback from NAME and NAME I responded. Of note: the introductory text in URL about the choice to make the format inflexible.

Related discussion:
text: acknowledgement (see HTTP2). Multiple updates to the maximum table size can occur between the <del> sending of two header blocks.  In the case that the value of this parameter is changed more than once, if any changed value is smaller than the new maximum size, the smallest value for the parameter MUST be sent in an encoding context update.  The altered maximum size is always sent, resulting in at most two encoding context updates.  This ensures that the decoder is able to perform eviction based on the decoder table size (see entry.eviction). </del> <ins> sending of two header blocks.  In the case that this size is changed more than once in this interval, the smallest maximum table size that occurs in that interval MUST be sent in an encoding context update. The final maximum size is always sent, resulting in at most two encoding context updates.  This ensures that the decoder is able to perform eviction based on reductions in decoder table size (see entry.eviction). </ins> This mechanism can be used to completely clear entries from the dynamic table by setting a maximum size of 0, which can subsequently