jiebi/CodeConvo huggingface dataset:
Code change:
We've seen varying amounts of advantage from having header table substitution enabled. Most are fairly minimal, even assuming perfect foresight. Some tests show single digit percentage improvements, others are much less. The feature adds some complexity. Is this complexity justified? Should we remove this feature?
Offline discussions: NAME and NAME agree that if this isn't removed, we should swap the opcodes so that substitution gets a worse (the longer) opcode.
Discussion in Seattle resulted in a conclusion to remove the substitution opcode from the draft.
Fixed in .

Related discussion:
text: A literal header with incremental indexing adds a new entry to the header table. <del> This representation starts with the '010' 3-bit pattern. If the header name matches the header name of a (name, value) pair stored in the Header Table, the index of the pair increased by one (index + 1) is represented as an integer with a 5-bit prefix.  Note that if the index is strictly below 31, one byte is used. If the header name does not match a header name entry, the value 0 is represented on 5 bits followed by the header name (header.name.representation). Header name representation is followed by the header value represented as a literal string as described in string.literal.representation. 4.3.3. A literal header with substitution indexing replaces an existing header table entry. </del> This representation starts with the '00' 2-bit pattern. If the header name matches the header name of a (name, value) pair
Code change:
We've seen varying amounts of advantage from having header table substitution enabled. Most are fairly minimal, even assuming perfect foresight. Some tests show single digit percentage improvements, others are much less. The feature adds some complexity. Is this complexity justified? Should we remove this feature?
Offline discussions: NAME and NAME agree that if this isn't removed, we should swap the opcodes so that substitution gets a worse (the longer) opcode.
Discussion in Seattle resulted in a conclusion to remove the substitution opcode from the draft.
Fixed in .

Related discussion:
text: represented on 6 bits followed by the header name (header.name.representation). <del> The index of the substituted (name, value) pair is inserted after the header name representation as a 0-bit prefix integer. The index of the substituted pair MUST correspond to a position in the header table containing a non-void entry.  An index for the substituted pair that corresponds to empty position in the header table MUST be treated as an error. This index is followed by the header value represented as a literal string as described in string.literal.representation. </del> <ins> Header name representation is followed by the header value represented as a literal string as described in string.literal.representation. </ins> 5.
Code change:
On Sun, Oct 20, 2013 at 05:23:50PM -0700, Roberto Peon wrote: Here's a proposal for that.

Related discussion:
text: The algorithm to represent an integer I is as follows: <ins> This integer representation allows for values of indefinite size.  It is also possible for an encoder to send a large number of zero values, which can waste bytes and could be used to overflow integer values.  Excessively large integer encodings - in value or octet length - MUST be treated as a decoding error.  Different limits can be set for each of the different uses of integers, based on implementation constraints. </ins> 4.1.1.1. The value 10 is to be encoded with a 5-bit prefix.
Code change:
On Sun, Oct 20, 2013 at 05:23:50PM -0700, Roberto Peon wrote: Here's a proposal for that.

Related discussion:
text: string comparisons is always a function of the total length of the strings, and not a function of the number of matched characters. <ins> A decoder needs to ensure that larger values or encodings of integers do not permit exploitation.  Decoders MUST limit the size of integers, both in value and encoded length, that it accepts (see integer.representation). </ins> Another common security problem is when the remote endpoint successfully causes the local endpoint to exhaust its memory.  This compressor attempts to deal with the most obvious ways that this
Code change:
Instructions for Indexed Representation of entry already in header table say to add entry to header table again, don't mention reference set.

Related discussion:
text: The header field corresponding to the referenced entry is emitted. <del> The referenced header table entry is added to the header table. </del> <ins> The referenced header table entry is added to the reference set. </ins> A _literal representation_ that is _not added_ to the header table entails the following action:
Code change:
We've long since agreed that full request headers are sent in the PUSHPROMISE frame; found a lingering reference to pushed resources "inheriting" headers from the original request. Revised it to reference the request headers in the PUSHPROMISE frame like everywhere else.

Related discussion:
text: triggered the push, plus resource identification information provided by the server.  Request header fields are necessary for HTTP cache control validations (such as the Vary header field) to work.  For <del> this reason, caches MUST inherit request header fields from the associated stream for the push.  This includes the Cookie header field. </del> <ins> this reason, caches MUST associate the request header fields from the PUSH_PROMISE frame with the response headers and content delivered on the pushed stream.  This includes the Cookie header field. </ins> Caching resources that are pushed is possible, based on the guidance provided by the origin server in the Cache-Control header field.
Code change:
This updates the concurrent streams in the XML and updates the HTML too (which picked up some other changes).
"For implementors it is recommended that this value be no smaller than 100" - what is the significance of "for implementers" here? I'm concerned this language is ambiguous enough to cause trouble. E.g., some may read it as pure advice; others might take away that values smaller than 100 can be assumed to be 100. Best way to specify is with MUST/SHOULD/MAY, identifying who it applies to (sender / recipient), and ideally specifying what should happen on both ends of the wire (when generating and receiving).
I agree this is ambiguous. I snuck in a short explanation there. I feel like we should take this back to the working group mailing list. I propose we either commit as is, as my extra explanatory clause is innocuous, and open an issue to resolve the ambiguity. Or I can withdraw this pull request for now, go back to the mailing list, and proceed with the flow control pull request first.
I'm happy to merge now and note an issue; just trying to minimise the number of such edits we cause with each change, as they have a tendency to stack up.

Related discussion:
text: frame from this client to the remote and receive a response. The value is represented in milliseconds. <del> 4 - SETTINGS_MAX_CONCURRENT_STREAMS allows the sender to inform the remote endpoint the maximum number of concurrent streams which it will allow.  By default there is no limit.  For </del> <ins> 4 - SETTINGS_MAX_CONCURRENT_STREAMS indicates the maximum number of concurrent streams which the sender of the SETTINGS frame is willing to allow the peer to open.  Note that this limit is directional.  By default there is no limit.  For </ins> implementors it is recommended that this value be no smaller <del> than 100. </del> <ins> than 100, so as not to unnecessarily limit parallelism. </ins> 5 - SETTINGS_CURRENT_CWND allows the sender to inform the remote endpoint of the current TCP CWND value.
Code change:
TLS Client Hello's between 256 and 512 bytes need to be rounded up to 512 for compatibility reasons. This incents us to keep Client Hello parameters as small as possible to avoid the rounding - this change shortens the ALPN token of HTTP/2.0 to be simply "h2"
Discussed in Zurich; we will take this and hold back the eventual heat death of the universe a byte at a time.

Related discussion:
text: 3.1. The protocol defined in this document is identified using the string <del> "HTTP/2.0".  This identification is used in the HTTP/1.1 Upgrade header field, in the TLSALPN field, and other places where protocol </del> <ins> "h2".  This identification is used in the HTTP/1.1 Upgrade header field, in the TLSALPN field, and other places where protocol </ins> identification is required. <del> Negotiating "HTTP/2.0" implies the use of the transport, security, framing and message semantics described in this document. </del> <ins> Negotiating "h2" implies the use of the transport, security, framing and message semantics described in this document. </ins> Only implementations of the final, published RFC can identify <del> themselves as "HTTP/2.0".  Until such an RFC exists, implementations MUST NOT identify themselves using "HTTP/2.0". </del> <ins> themselves as "h2".  Until such an RFC exists, implementations MUST NOT identify themselves using "h2". </ins> <del> Examples and text throughout the rest of this document use "HTTP/2.0" as a matter of editorial convenience only.  Implementations of draft versions MUST NOT identify using this string.  The exception to this rule is the string included in the connection header sent by clients immediately after establishing an HTTP/2.0 connection (see ConnectionHeader); this fixed length sequence of octets does not change. </del> <ins> Examples and text throughout the rest of this document use "h2" as a matter of editorial convenience only.  Implementations of draft versions MUST NOT identify using this string. </ins> Implementations of draft versions of the protocol MUST add the string <del> "-draft-" and the corresponding draft number to the identifier before the separator ('/').  For example, draft-ietf-httpbis-http2-03 is identified using the string "HTTP-draft-03/2.0". </del> <ins> "-" and the corresponding draft number to the identifier.  For example, draft-ietf-httpbis-http2-09 is identified using the string "h2-09". </ins> Non-compatible experiments that are based on these draft versions <del> MUST instead replace the string "draft" with a different identifier. </del> <ins> MUST append the string "-" and a experiment name to the identifier. </ins> For example, an experimental implementation of packet mood-based <del> encoding based on draft-ietf-httpbis-http2-07 might identify itself as "HTTP-emo-07/2.0".  Note that any label MUST conform to the "token" syntax defined in HTTP-p1.  Experimenters are encouraged to </del> <ins> encoding based on draft-ietf-httpbis-http2-09 might identify itself as "h2-09-emo".  Note that any label MUST conform to the "token" syntax defined in HTTP-p1.  Experimenters are encouraged to </ins> coordinate their experiments on the ietf-http-wg@w3.org mailing list. 3.2.
Code change:
TLS Client Hello's between 256 and 512 bytes need to be rounded up to 512 for compatibility reasons. This incents us to keep Client Hello parameters as small as possible to avoid the rounding - this change shortens the ALPN token of HTTP/2.0 to be simply "h2"
Discussed in Zurich; we will take this and hold back the eventual heat death of the universe a byte at a time.

Related discussion:
text: A client that makes a request to an "http" URI without prior knowledge about support for HTTP/2.0 uses the HTTP Upgrade mechanism (HTTP-p1).  The client makes an HTTP/1.1 request that includes an <del> Upgrade header field identifying HTTP/2.0.  The HTTP/1.1 request MUST include exactly one Http2SettingsHeader header field. </del> <ins> Upgrade header field identifying HTTP/2.0 with the h2 token.  The HTTP/1.1 request MUST include exactly one Http2SettingsHeader header field. </ins> Requests that contain an entity body MUST be sent in their entirety before the client can send HTTP/2.0 frames.  This means that a large
Code change:
TLS Client Hello's between 256 and 512 bytes need to be rounded up to 512 for compatibility reasons. This incents us to keep Client Hello parameters as small as possible to avoid the rounding - this change shortens the ALPN token of HTTP/2.0 to be simply "h2"
Discussed in Zurich; we will take this and hold back the eventual heat death of the universe a byte at a time.

Related discussion:
text: HTTP/2.0 <del> 0x48 0x54 0x54 0x50 0x2f 0x32 0x2e 0x30 ("HTTP/2.0") </del> <ins> 0x68 0x32 ("h2") </ins> This document (RFCXXXX)
Code change:
In URL;list=ietf-http-wg, it was proposed that the PRI method be reserved in the HTTP/1.1 method registration document to avoid possible future reservation and ensure that the magic string remains a reliable way of differentiating HTTP/1.1 connections from HTTP/2.0 connections. There was a +1 and some offline discussion along the same vein, no dissent that I heard or saw. However, I don’t see it in URL, presumably because no RFC exists to reference. The appropriate doc is probably HTTP/2.0 rather than breaking the glass on the prepopulated registrations.
There was a question whether "SM" should also be reserved; I personally don't think so, since that line will never be interpreted as a potentially-valid HTTP request line or header. However, I don't think it would break anything if we did.
Break things, no. Squat on prime name-real-estate, a little.

Related discussion:
text: A client can learn that a particular server supports HTTP/2.0 by other means.  A client MAY immediately send HTTP/2.0 frames to a server that is known to support HTTP/2.0, after the ConnectionHeader. <del> This only affects the resolution of "http" URIs; servers supporting HTTP/2.0 are required to support TLSALPN for "https" URIs. </del> <ins> A server can identify such a connection by the use of the "PRI" method in the connection header.  This only affects the resolution of "http" URIs; servers supporting HTTP/2.0 are required to support TLSALPN for "https" URIs. </ins> Prior support for HTTP/2.0 is not a strong signal that a given server will support HTTP/2.0 for future connections.  It is possible for
Code change:
In URL;list=ietf-http-wg, it was proposed that the PRI method be reserved in the HTTP/1.1 method registration document to avoid possible future reservation and ensure that the magic string remains a reliable way of differentiating HTTP/1.1 connections from HTTP/2.0 connections. There was a +1 and some offline discussion along the same vein, no dissent that I heard or saw. However, I don’t see it in URL, presumably because no RFC exists to reference. The appropriate doc is probably HTTP/2.0 rather than breaking the glass on the prepopulated registrations.
There was a question whether "SM" should also be reserved; I personally don't think so, since that line will never be interpreted as a potentially-valid HTTP request line or header. However, I don't think it would break anything if we did.
Break things, no. Squat on prime name-real-estate, a little.

Related discussion:
text: This document registers the "HTTP2-Settings" header field for use in HTTP. <ins> This document registers the "PRI" method for use in HTTP, to avoid collisions with the ConnectionHeader. </ins> 12.1. This document creates a registration for the identification of
Code change:
In URL;list=ietf-http-wg, it was proposed that the PRI method be reserved in the HTTP/1.1 method registration document to avoid possible future reservation and ensure that the magic string remains a reliable way of differentiating HTTP/1.1 connections from HTTP/2.0 connections. There was a +1 and some offline discussion along the same vein, no dissent that I heard or saw. However, I don’t see it in URL, presumably because no RFC exists to reference. The appropriate doc is probably HTTP/2.0 rather than breaking the glass on the prepopulated registrations.
There was a question whether "SM" should also be reserved; I personally don't think so, since that line will never be interpreted as a potentially-valid HTTP request line or header. However, I don't think it would break anything if we did.
Break things, no. Squat on prime name-real-estate, a little.

Related discussion:
text: This header field is only used by an HTTP/2.0 client for Upgrade- based negotiation. <ins> 12.6. This section registers the "PRI" method in the HTTP-p2. PRI No No ConnectionHeader of this document This method is never used by an actual client.  This method will appear to be used when an HTTP/1.1 server or intermediary attempts to parse an HTTP/2.0 connection known-http. </ins>
Code change:
The sentence in 8.3: "CONNECT is primarily used with HTTP proxies to established a TLS session with a server for the purposes of interacting with https resources." ... does not read. I believe it should be: "CONNECT is primarily used with HTTP proxies to establish a TLS session with a server for the purposes of interacting with https resources." This pull request fixes this incredibly minor issue.

Related discussion:
text: The HTTP pseudo-method CONNECT (HTTP-p2) is used to convert an HTTP/1.1 connection into a tunnel to a remote host.  CONNECT is <del> primarily used with HTTP proxies to established a TLS session with a </del> <ins> primarily used with HTTP proxies to establish a TLS session with a </ins> server for the purposes of interacting with "https" resources. In HTTP/2.0, the CONNECT method is used to establish a tunnel over a
Code change:
Felt that this order was clearer since the requirement then back-referenced the previous flag instead of forward-referencing it. Feel free to ignore if you disagree.
I considered that option. I think that it's easier if the order of the bits is the same as the order the fields appear. I'll reopen and take this if others point this out though.
Confused by that. In the as-written docs the flags are: [R, R, R, R, PADLOW, PADHIGH, R, ENDSTREAM] but the frame layout is: [PADHIGH (8)], [PAD_LOW(8)] so the order of the bits is opposite the field order.
Let's chalk this up as yet another case of blindness on my part.

Related discussion:
text: Bit 2 is reserved for future use. <del> Bit 3 being set indicates that the Pad High field is present. This bit MUST NOT be set unless the PAD_LOW flag is also set. </del> <ins> Bit 3 being set indicates that the Pad Low field is present. </ins> <del> Bit 4 being set indicates that the Pad Low field is present. </del> <ins> Bit 4 being set indicates that the Pad High field is present. This bit MUST NOT be set unless the PAD_LOW flag is also set. </ins> DATA frames MUST be associated with a stream.  If a DATA frame is received whose stream identifier field is 0x0, the recipient MUST
Code change:
Editorial changes through Section 3.1.2. Further updates forthcoming.
Rebased onto current master.

Related discussion:
text: Abstract <del> This document describes HPACK, a format adapted to efficiently represent HTTP header fields in the context of HTTP/2. </del> <ins> This specification defines HPACK, a compression format for efficiently representing HTTP header fields in the context of HTTP/2. </ins> Editorial Note (To be removed by RFC Editor)
Code change:
Editorial changes through Section 3.1.2. Further updates forthcoming.
Rebased onto current master.

Related discussion:
text: The encoding and decoding of header fields relies on some components and concepts: <del> A name-value pair.  Both name and value are sequences of octets. </del> <ins> A name-value pair.  Both the name and value are treated as opaque sequences of octets. </ins> The header table (see header.table) is a component used to <del> associate stored header fields to index values.  The data stored in this table is in first-in, first-out order. </del> <ins> associate stored header fields to index values. </ins> The static table (see static.table) is a component used to associate static header fields to index values.  This data is
Code change:
Editorial changes through Section 3.1.2. Further updates forthcoming.
Rebased onto current master.

Related discussion:
text: unordered set of references to entries in the header table.  This is used for the differential encoding of a new header set. <del> A header set is a potentially ordered group of header fields that are encoded jointly.  A complete set of key-value pairs contained in a HTTP request or response is a header set. </del> <ins> A header set is an unordered group of header fields that are encoded jointly.  A complete set of key-value pairs contained in a HTTP request or response is a header set. </ins> A header field can be represented in encoded form either as a literal or as an index (see header.representation).
Code change:
Editorial changes through Section 3.1.2. Further updates forthcoming.
Rebased onto current master.

Related discussion:
text: When decoding a set of header field representations, some operations emit a header field (see header.emission).  Emitted <del> header fields can be safely passed to the upper processing layers as part of the current Header Set. </del> <ins> header fields are added to the current header set and cannot be removed. </ins> 3.1.1.
Code change:
Editorial changes through Section 3.1.2. Further updates forthcoming.
Rebased onto current master.

Related discussion:
text: a header table and a reference set.  Everything else is either immutable or conceptual. <del> Using HTTP, messages are exchanged between a client and a server in both direction.  To keep the encoding of header fields in each direction independent from the other direction, there is one encoding context for each direction. The header fields contained in a PUSH_PROMISE frame sent by a server to a client are encoded within the same context as the header fields contained in the HEADERS frame corresponding to a response sent from the server to the client. </del> <ins> HTTP messages are exchanged between a client and a server in both directions.  The encoding of header fields in each direction is independent from the other direction.  There is a single encoding context for each direction used to encode all header fields sent in that direction. </ins> 3.1.2.
Code change:
Editorial changes through Section 3.1.2. Further updates forthcoming.
Rebased onto current master.

Related discussion:
text: The encoder decides how to update the header table and as such can control how much memory is used by the header table.  To limit the <del> memory requirements on the decoder side, the header table size is strictly bounded (see maximum.table.size). </del> <ins> memory requirements of the decoder, the header table size is strictly bounded (see maximum.table.size). </ins> The header table is updated during the processing of a set of header field representations (see header.representation.processing).