jiebi/CodeConvo huggingface dataset:
Code change:
Also reservers flag 0x2 in DATA and HEADERS frames and renumbers flags accordingly.
Please feel free to exercise editorial privilege with respect to wording. Reserving 0x2 at NAME requests.

Related discussion:
text: An 8-bit field reserved for frame-type specific boolean flags. <del> The least significant bit (0x1) - the END_STREAM bit - is defined for all frame types as an indication that this frame is the last the endpoint will send for the identified stream.  Setting this flag causes the stream to enter the StreamHalfClose. Implementations MUST process the END_STREAM bit for all frames whose stream identifier field is not 0x0.  The END_STREAM bit MUST NOT be set on frames that use a stream identifier of 0. The remaining flags can be assigned semantics specific to the indicated frame type.  Flags that have no defined semantics for a particular frame type MUST be ignored, and MUST be left unset (0) when sending. </del> <ins> Flags are assigned semantics specific to the indicated frame type. Flags that have no defined semantics for a particular frame type MUST be ignored, and MUST be left unset (0) when sending. </ins> A reserved 1-bit field.  The semantics of this bit are undefined and the bit MUST remain unset (0) when sending and MUST be ignored
Code change:
Also reservers flag 0x2 in DATA and HEADERS frames and renumbers flags accordingly.
Please feel free to exercise editorial privilege with respect to wording. Reserving 0x2 at NAME requests.

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> The DATA frame does not define any type-specific flags. </del> <ins> The DATA frame defines the following flags: Bit 1 being set indicates that this frame is the last that the endpoint will send for the identified stream.  Setting this flag causes the stream to enter the StreamHalfClose. Bit 2 is reserved for future use. </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:
Also reservers flag 0x2 in DATA and HEADERS frames and renumbers flags accordingly.
Please feel free to exercise editorial privilege with respect to wording. Reserving 0x2 at NAME requests.

Related discussion:
text: The payload of a PRIORITY frame contains a single reserved bit and a 31-bit priority. <del> The PRIORITY frame does not define any type-specific flags. </del> <ins> The PRIORITY frame does not define any flags. </ins> The PRIORITY frame is associated with an existing stream.  If a PRIORITY frame is received with a stream identifier of 0x0, the
Code change:
Also reservers flag 0x2 in DATA and HEADERS frames and renumbers flags accordingly.
Please feel free to exercise editorial privilege with respect to wording. Reserving 0x2 at NAME requests.

Related discussion:
text: values for parameters whose values have already been established. Only the most recent value provided setting value applies. <del> The SETTINGS frame does not have any frame specific flags. </del> <ins> The SETTINGS frame does not define any flags. </ins> SETTINGS frames always apply to a connection, never a single stream. The stream identifier for a settings frame MUST be zero.  If an
Code change:
Also reservers flag 0x2 in DATA and HEADERS frames and renumbers flags accordingly.
Please feel free to exercise editorial privilege with respect to wording. Reserving 0x2 at NAME requests.

Related discussion:
text: payload.  PING responses SHOULD given higher priority than any other frame. <del> The PING frame defines one type-specific flag: </del> <ins> The PING frame defines the following flags: </ins> <del> Bit 2 being set indicates that this PING frame is a PING response. </del> <ins> Bit 1 being set indicates that this PING frame is a PING response. </ins> An endpoint MUST set this flag in PING responses.  An endpoint MUST NOT respond to PING frames containing this flag.
Code change:
Also reservers flag 0x2 in DATA and HEADERS frames and renumbers flags accordingly.
Please feel free to exercise editorial privilege with respect to wording. Reserving 0x2 at NAME requests.

Related discussion:
text: After sending a GOAWAY frame, the sender can ignore frames for new streams. <del> The GOAWAY frame does not define any type-specific flags. </del> <ins> The GOAWAY frame does not define any flags. </ins> The GOAWAY frame applies to the connection, not a specific stream. The stream identifier MUST be zero.
Code change:
Also reservers flag 0x2 in DATA and HEADERS frames and renumbers flags accordingly.
Please feel free to exercise editorial privilege with respect to wording. Reserving 0x2 at NAME requests.

Related discussion:
text: Any number of HEADERS frames can may be sent on an existing stream at any time. <del> Additional type-specific flags for the HEADERS frame are: </del> <ins> The HEADERS frame defines the following flags: Bit 1 being set indicates that this frame is the last that the endpoint will send for the identified stream.  Setting this flag causes the stream to enter the StreamHalfClose. Bit 2 is reserved for future use. </ins> The END_HEADERS bit indicates that this frame contains the entire payload necessary to provide a complete set of headers.
Code change:
Also reservers flag 0x2 in DATA and HEADERS frames and renumbers flags accordingly.
Please feel free to exercise editorial privilege with respect to wording. Reserving 0x2 at NAME requests.

Related discussion:
text: respond with a StreamErrorHandler or ConnectionErrorHandler of type FLOW_CONTROL_ERROR if it is unable accept a frame. <del> The following additional flags are defined for the WINDOW_UPDATE frame: </del> <ins> The WINDOW_UPDATE frame defines the following flags: </ins> <del> Bit 2 being set indicates that flow control for the identified </del> <ins> Bit 1 being set indicates that flow control for the identified </ins> stream or connection has been ended; subsequent frames do not need to be flow controlled.
Code change:
As discussed in the interim... (I had previously submitted this in a batch against the Layering branch... redoing against the Master)
Looks good for the most part, consider the comments as advisory only.

Related discussion:
text: 3.3. <del> Once the HTTP/2.0 connection is established, clients and servers can begin exchanging frames. </del> <ins> Once the HTTP/2.0 connection is established, endpoints can begin exchanging frames. </ins> 3.3.1. <del> HTTP/2.0 frames share a common base format consisting of an 8-byte header followed by 0 to 65535 bytes of data. </del> <ins> All frames share a common base format consisting of an 8-byte header followed by 0 to 65,535 octets of payload data. </ins> The fields of the frame header are defined as:
Code change:
As discussed in the interim... (I had previously submitted this in a batch against the Layering branch... redoing against the Master)
Looks good for the most part, consider the comments as advisory only.

Related discussion:
text: 3.3.2. <del> Implementations with limited resources might not be capable of processing large frame sizes.  Such implementations MAY choose to place additional limits on the maximum frame size.  However, all implementations MUST be capable of receiving and processing frames containing at least 8192 octets of data. An implementation MUST terminate a stream immediately if it is unable to process a frame due it's size.  This is done by sending an RST_STREAM containing the FRAME_TOO_LARGE error code. </del> <ins> The maximum amount of payload data any frame can contain varies by frame type and use.  The absolute maximum amount of payload data any individual frame can contain is 65,535 octets.  All implementations SHOULD be capable of receiving and minimally processing frames up to this size. Certain frame types, such as PING (see PING), impose strict limits on the amount of payload data allowed.  Likewise, additional size limits can be set by specific application uses.  For instance, individual DATA and HEADERS frames used to express HTTP request and response messages (see HTTPLayer) are not permitted to exceed 16,383 octets of payload.  Sending endpoints MUST NOT exceed such limits. If an endpoint is unable to process a frame due to the payload size, or if the size exceeds a strictly defined limit, the endpoint MUST send a FRAME_TOO_LARGE error.  If the frame stream identifier is 0x0, this code MUST be sent as a connection error.  If the stream identifier is anything other than 0x0, it is sent as a stream error. </ins> 3.4.
Code change:
:Client advertising settings during Upgrade dance URL
I assume that this header field is hop-by-hop in the HTTP/1.1 sense and should appear in the Connection header field.
Ooops, yes! Just checked that in.
This issue is to track whether the client should advertise its settings (e.g. contents of SETTINGS frame) as part of the Upgrade GET (e.g. as HTTP/1.1 headers in the GET request). Normally, the first HTTP/2.0 frame the client emits is the SETTINGS frame. This means the server will receive the client's settings before getting the SYNSTREAM from the client. However, in the Upgrade Dance the server receives the GET and has to respond with a 101 HTTP/1.1 response followed by the HTTP/2.0 SYNREPLY. The ugliness here is that the server will be in a situation where it has to send the SYN_REPLY (and possibly DATA frames and possibly start push streams) without knowing the client's settings. This means the server may blow the client’s flow control buffers, or emit a pushed stream even though the client is incapable of processing pushed streams, etc. If we include the settings as part of the initial Upgrade GET then 1) Server receives the pre-requisite initials settings and the initial GET request in a single package. Makes life simpler. 2) Brings us to parity with the SSL route where the server will have the cilent's SETTINGS before it starts working on the initial request.
Discussed at SF Interim; targetting 1st implementation draft. Gabriel to make proposal.
Addressed via "HTTP2-Settings Header Field" section.

Related discussion:
text: The following terms are used: <ins> The URL- and filename-safe Base64 encoding described in RFC4648, Section 5, with the (non URL- safe) '=' padding characters omitted, as permitted by RFC 4648, Section 3.2. </ins> The endpoint initiating the HTTP connection. A transport-level connection between two endpoints.
Code change:
:Client advertising settings during Upgrade dance URL
I assume that this header field is hop-by-hop in the HTTP/1.1 sense and should appear in the Connection header field.
Ooops, yes! Just checked that in.
This issue is to track whether the client should advertise its settings (e.g. contents of SETTINGS frame) as part of the Upgrade GET (e.g. as HTTP/1.1 headers in the GET request). Normally, the first HTTP/2.0 frame the client emits is the SETTINGS frame. This means the server will receive the client's settings before getting the SYNSTREAM from the client. However, in the Upgrade Dance the server receives the GET and has to respond with a 101 HTTP/1.1 response followed by the HTTP/2.0 SYNREPLY. The ugliness here is that the server will be in a situation where it has to send the SYN_REPLY (and possibly DATA frames and possibly start push streams) without knowing the client's settings. This means the server may blow the client’s flow control buffers, or emit a pushed stream even though the client is incapable of processing pushed streams, etc. If we include the settings as part of the initial Upgrade GET then 1) Server receives the pre-requisite initials settings and the initial GET request in a single package. Makes life simpler. 2) Brings us to parity with the SSL route where the server will have the cilent's SETTINGS before it starts working on the initial request.
Discussed at SF Interim; targetting 1st implementation draft. Gabriel to make proposal.
Addressed via "HTTP2-Settings Header Field" section.

Related discussion:
text: An initial set of settings registrations can be found in SettingValues. <ins> 8.4. 8.4.1. This section describes a header field for registration in the Permanent Message Header Field Registry.  RFC3864 HTTP2-Settings http standard IETF RFC XXXX (this document) This header field is only used by the client in the Upgrade-based negotiation. The HTTP2-Settings header field is used in the Upgrade-based negotiation by the client.  It is sent from the client to the server to provide the payload for its SETTINGS frame in anticipation of the server responding with HTTP/2.0 frames. The HTTP2-Settings header field MUST NOT appear more than once in an HTTP request and MUST NOT appear at all in an HTTP response. </ins>
Code change:
half closed (client/server) is no longer used. :scheme header MUST include HTTP Request
NAME The fixes of the commit of 73dce91fcccecce7079d7ccf6294e80350d5ce19 were somehow lost after ea5abcf90460dc300b94eb27d82162f56a1dc526 . I'm not sure why it happened without conflicting. Please fix them by your hand.
Will do. It's easy enough to fix.

Related discussion:
text: From this state either peer can send a frame with a END_STREAM flag set, which causes the stream to transition into one of the <del> "half closed" states: a client sending a END_STREAM flag causes the stream state to become "half closed (client)"; a server sending a END_STREAM flag causes the stream state to become "half closed (server)". </del> <ins> "half closed" states: an endpoint sending a END_STREAM flag causes the stream state to become "half closed (local)"; an endpoind receiving a END_STREAM flag causes the stream state to become "half closed (remote)". </ins> An endpoint can send RST_STREAM from this state, causing it to transition immediately to "closed".
Code change:
I think this is strictly an editorial clarification, not a technical change, but something that came up in discussions within the team. If there's any question about that, feel free to push it back and we'll discuss on-list.
This looks like , sort of. I think that we need a little more than what you include here. This covers the initial SETTINGS frame, but there are bits in 3.8.5 that need fixing too.
Similar issue, different layer…. is talking about multiple instances of the same setting value in a single SETTINGS frame. This commit is talking about multiple instances of the “HTTP2-Settings” header in an HTTP/1.1 request that’s offering Upgrade. From: martinthomson [mailto:EMAIL] Sent: Thursday, July 18, 2013 3:49 PM To: http2/http2-spec Cc: Mike Bishop Subject: Re: [http2-spec] Clarify no duplicate instances of HTTP2-Settings () This looks like URL, sort of. I think that we need a little more than what you include here. This covers the initial SETTINGS frame, but there are bits in 3.8.5 that need fixing too. — Reply to this email directly or view it on URL
Ahh, I don't see this as a big deal, since "a header field" and "exactly one header field" seem equivalent to me. I'll pull it in.

Related discussion:
text: 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 Upgrade header field identifying HTTP/2.0.  The HTTP/1.1 request MUST <del> include an Http2SettingsHeader header field. </del> <ins> include exactly one Http2SettingsHeader header field. </ins> Requests that contain a request entity body MUST be sent in their entirety before the client can send HTTP/2.0 frames.  This means that
Code change:
I think this is strictly an editorial clarification, not a technical change, but something that came up in discussions within the team. If there's any question about that, feel free to push it back and we'll discuss on-list.
This looks like , sort of. I think that we need a little more than what you include here. This covers the initial SETTINGS frame, but there are bits in 3.8.5 that need fixing too.
Similar issue, different layer…. is talking about multiple instances of the same setting value in a single SETTINGS frame. This commit is talking about multiple instances of the “HTTP2-Settings” header in an HTTP/1.1 request that’s offering Upgrade. From: martinthomson [mailto:EMAIL] Sent: Thursday, July 18, 2013 3:49 PM To: http2/http2-spec Cc: Mike Bishop Subject: Re: [http2-spec] Clarify no duplicate instances of HTTP2-Settings () This looks like URL, sort of. I think that we need a little more than what you include here. This covers the initial SETTINGS frame, but there are bits in 3.8.5 that need fixing too. — Reply to this email directly or view it on URL
Ahh, I don't see this as a big deal, since "a header field" and "exactly one header field" seem equivalent to me. I'll pull it in.

Related discussion:
text: 3.2.1. <del> A client that upgrades from HTTP/1.1 to HTTP/2.0 MUST include an "HTTP2-Settings" header field.  The "HTTP2-Settings" header field is a hop-by-hop header field that includes settings that govern the </del> <ins> A client that upgrades from HTTP/1.1 to HTTP/2.0 MUST include exactly one "HTTP2-Settings" header field.  The "HTTP2-Settings" header field is a hop-by-hop header field that includes settings that govern the </ins> HTTP/2.0 connection, provided in anticipation of the server accepting the request to upgrade.  A server MUST reject an attempt to upgrade if this header is not present.
Code change:
Fixed the word "client" to "request" on "HTTP2-Settings Header Field".

Related discussion:
text: 3.2.1. <del> A client that upgrades from HTTP/1.1 to HTTP/2.0 MUST include exactly one "HTTP2-Settings" header field.  The "HTTP2-Settings" header field is a hop-by-hop header field that includes settings that govern the HTTP/2.0 connection, provided in anticipation of the server accepting the request to upgrade.  A server MUST reject an attempt to upgrade if this header is not present. </del> <ins> A request that upgrades from HTTP/1.1 to HTTP/2.0 MUST include exactly one "HTTP2-Settings" header field.  The "HTTP2-Settings" header field is a hop-by-hop header field that includes settings that govern the HTTP/2.0 connection, provided in anticipation of the server accepting the request to upgrade.  A server MUST reject an attempt to upgrade if this header is not present. </ins> The content of the "HTTP2-Settings" header field is the payload of a
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 either literally or as a reference to an entry of the header table.  The header value is represented literally. <del> Three different literal representations are provided: </del> <ins> Two different literal representations are provided: </ins> A literal representation that does not add the header to the header table (see literal.header.without.indexing). <del> A literal representation that adds the header at the end of the header table (see literal.header.with.incremental.indexing). A literal representation that uses the header to replace an existing entry of the header table (see literal.header.with.substitution.indexing). </del> <ins> A literal representation that adds the header at the beginning of the header table (see literal.header.with.incremental.indexing). </ins> The indexed representation defines a header as a reference in the header table (see indexed.header.representation).
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: or by replacing an existing one.  Before doing such a modification, it has to be ensured that the header table size will stay lower than or equal to the SETTINGS_HEADER_TABLE_SIZE limit (see <del> parameter.negotiation).  To achieve this, repeatedly, the first entry </del> <ins> parameter.negotiation).  To achieve this, repeatedly, the last entry </ins> of the header table is removed, until enough space is available for the modification.
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: header table is that the remaining entries are renumbered.  The first entry of the header table is always associated to the index 0. <del> When the modification of the header table is the replacement of an existing entry, the replaced entry is the one indicated in the literal representation before any entry is removed from the header table.  If the entry to be replaced is removed from the header table when performing the size adjustment, the replacement entry is inserted at the beginning of the header table. </del> The addition of a new entry with a size greater than the SETTINGS_HEADER_TABLE_SIZE limit causes all the entries from the header table to be dropped and the new entry not to be added to the <del> header table.  The replacement of an existing entry with a new entry with a size greater than the SETTINGS_HEADER_TABLE_SIZE has the same consequences. </del> <ins> header table. </ins> 4.
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 without indexing causes the emission of a header without altering the header table. <del> This representation starts with the '011' 3-bit pattern. </del> <ins> This representation starts with the '01' 2-bit pattern. </ins> 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 <del> (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. </del> <ins> (index + 1) is represented as an integer with a 6-bit prefix.  Note that if the index is strictly below 63, one byte is used. </ins> If the header name does not match a header name entry, the value 0 is <del> represented on 5 bits followed by the header name </del> <ins> represented on 6 bits followed by the header name </ins> (header.name.representation). Header name representation is followed by the header value