jiebi/CodeConvo huggingface dataset:
Code change:
NAME did you just forget to create the pull request?
Didn't realize you couldn't merge from the referenced issue. What do you need from me to merge the commit?
Just some indication that you think that this is ready, that's all.
Do you think we need to add a requirement for must emit? or is the not coalesce sufficient?
Now that you mention it, MUST preserve is really what we are going for.
added "MUST preserve"
There is some usefulness from both an extensibility perspective and a load balancing perspective to indicate multiple messages over an individual stream. This issue is to un-reserve the 0x02 END_MESSAGE flag to ensure that intermediaries that are deployed proxy the flag so that they are agnostic to the layered protocol and can still successfully load balance messages appropriately.
Note that this places a requirement on proxies that they cannot coalesce data frames across "END_MESSAGE" boundaries.
Discussed in Zurich with no real conclusion. Support and opposition were weak.
Discussed in Zurich; accepted in principle. Jeff to do a pull request.
Renamed ENDMESSAGE to ENDSEGMENT to avoid any confusion with HTTP messages. Feel free to re-name. Couldn't find any text that stated intermediaries could combine frames but may want to add a requirement that intermediaries must re-emit the flag at the same byte position.

Related discussion:
text: endpoint will send for the identified stream.  Setting this flag causes the stream to enter one of StreamStates. <del> Bit 2 is reserved for future use. </del> <ins> Bit 2 being set indicates that this frame is the last for the current segment.  Intermediaries MUST NOT coalesce frames across a segment boundary and MUST preserve segment boundaries when forwarding frames. </ins> Bit 3 being set indicates that the Pad Low field is present.
Code change:
This is a really minor thing, but as I was reading the spec, I was wondering for a bit what "extensions" meant (user defined? something else?). I think the intent is to reference extensions defined by future RFCs that revise HTTP/2 protocol.

Related discussion:
text: Implementations MUST support all of the settings defined by this specification and MAY support additional settings defined by <del> extensions.  Unsupported or unrecognized settings MUST be ignored. New settings MUST NOT be defined or implemented in a way that requires endpoints to understand them in order to communicate successfully. </del> <ins> extensions to this protocol.  Unsupported or unrecognized settings MUST be ignored.  New settings MUST NOT be defined or implemented in a way that requires endpoints to understand them in order to communicate successfully. </ins> Each setting in a SETTINGS frame replaces the existing value for that setting.  Settings are processed in the order in which they appear,
Code change:
Padding is made to a frame and other frames (DATA and CONTINUATION) have these 2 bytes right after the frame header. It is easier for implementation to put the same constructs in the same position.

Related discussion:
text: The HEADERS frame payload has the following fields: <ins> Padding size high bits.  This field is only present if the PAD_HIGH flag is set. Padding size low bits.  This field is only present if the PAD_LOW flag is set. </ins> A single reserved bit.  This field is optional and is only present if the PRIORITY flag is set.
Code change:
Padding is made to a frame and other frames (DATA and CONTINUATION) have these 2 bytes right after the frame header. It is easier for implementation to put the same constructs in the same position.

Related discussion:
text: This field is optional and is only present if the PRIORITY flag is set. <del> Padding size high bits.  This field is only present if the PAD_HIGH flag is set. Padding size low bits.  This field is only present if the PAD_LOW flag is set. </del> A HeaderBlock. Padding octets.
Code change:
This simplifies the text and makes flag consistent with CONTINUATION which only bears ENDHEADERS. Technically, both have the same meaning of ending sequence of header block fragments. Therefore there is no reason to use the different flag name for the same purpose. This will also make the implementaion easier because most likely HEADERS and PUSHPROMISE handling share the same code and dancing with ENDPUSHPROMISE and END_HEADERS is not fun. Although currently they have the same number, it is not guaranteed to the last. If they are guarenteed to be the same, then it is simpler to use the same name for same value.

Related discussion:
text: or <del> frame, with the END_HEADERS or END_PUSH_PROMISE flag set, or </del> <ins> frame, with the END_HEADERS flag set, or </ins> a or <del> frame with the END_HEADERS or END_PUSH_PROMISE flag cleared and one or more </del> <ins> frame with the END_HEADERS flag cleared and one or more </ins> frames, where the last
Code change:
This simplifies the text and makes flag consistent with CONTINUATION which only bears ENDHEADERS. Technically, both have the same meaning of ending sequence of header block fragments. Therefore there is no reason to use the different flag name for the same purpose. This will also make the implementaion easier because most likely HEADERS and PUSHPROMISE handling share the same code and dancing with ENDPUSHPROMISE and END_HEADERS is not fun. Although currently they have the same number, it is not guaranteed to the last. If they are guarenteed to be the same, then it is simpler to use the same name for same value.

Related discussion:
text: or <del> frames MUST have the END_PUSH_PROMISE or END_HEADERS flag set (respectively). </del> <ins> frames MUST have the END_HEADERS flag set. </ins> Header block fragments can only be sent as the payload of
Code change:
This simplifies the text and makes flag consistent with CONTINUATION which only bears ENDHEADERS. Technically, both have the same meaning of ending sequence of header block fragments. Therefore there is no reason to use the different flag name for the same purpose. This will also make the implementaion easier because most likely HEADERS and PUSHPROMISE handling share the same code and dancing with ENDPUSHPROMISE and END_HEADERS is not fun. Although currently they have the same number, it is not guaranteed to the last. If they are guarenteed to be the same, then it is simpler to use the same name for same value.

Related discussion:
text: , <del> or CONTINUATION without the END_HEADERS or END_PUSH_PROMISE flag set. </del> <ins> or CONTINUATION without the END_HEADERS flag set. </ins> The CONTINUATION frame payload has the following fields:
Code change:
l.815 before: An endpoint MUST NOT send frames other than than HEADERS/x:ref or fix: An endpoint MUST NOT send frames other than HEADERS/x:ref or

Related discussion:
text: The HTTP/2 specification is split into four parts: <del> starting covers how a HTTP/2 connection is initiated. </del> <ins> starting covers how an HTTP/2 connection is initiated. </ins> The FramingLayer and StreamsLayer layers describe the way HTTP/2 frames are structured and formed into multiplexed streams.
Code change:
l.815 before: An endpoint MUST NOT send frames other than than HEADERS/x:ref or fix: An endpoint MUST NOT send frames other than HEADERS/x:ref or

Related discussion:
text: 6.9.2. <del> When a HTTP/2 connection is first established, new streams are </del> <ins> When an HTTP/2 connection is first established, new streams are </ins> created with an initial flow control window size of 65,535 bytes. The connection flow control window is 65,535 bytes.  Both endpoints can adjust the initial window size for new streams by including a
Code change:
l.815 before: An endpoint MUST NOT send frames other than than HEADERS/x:ref or fix: An endpoint MUST NOT send frames other than HEADERS/x:ref or

Related discussion:
text: conveyed by other means.  As such, a HTTP/2 message containing Connection MUST be treated as malformed. <del> This means that an intermediary transforming a HTTP/1.x message to </del> <ins> This means that an intermediary transforming an HTTP/1.x message to </ins> HTTP/2 will need to remove any header fields nominated by the Connection header field, along with the Connection header field itself.  Such intermediaries SHOULD also remove other connection-
Code change:
l.815 before: An endpoint MUST NOT send frames other than than HEADERS/x:ref or fix: An endpoint MUST NOT send frames other than HEADERS/x:ref or

Related discussion:
text: Connection. One exception to this is the TE header field, which MAY be present in <del> a HTTP/2 request, but when it is MUST NOT contain any value other </del> <ins> an HTTP/2 request, but when it is MUST NOT contain any value other </ins> than "trailers". HTTP/2 purposefully does not support upgrade to another protocol.
Code change:
l.815 before: An endpoint MUST NOT send frames other than than HEADERS/x:ref or fix: An endpoint MUST NOT send frames other than HEADERS/x:ref or

Related discussion:
text: Clients receiving a pushed response MUST validate that the server is authorized to push it using the same-origin policy (RFC6454).  For <del> example, a HTTP/2 connection to "example.com" is generally </del> <ins> example, an HTTP/2 connection to "example.com" is generally </ins> "www.example.org". 8.3.
Code change:
l.815 before: An endpoint MUST NOT send frames other than than HEADERS/x:ref or fix: An endpoint MUST NOT send frames other than HEADERS/x:ref or

Related discussion:
text: Due to implementation limitations, it might not be possible to fail TLS negotiation based on all of these requirements.  An endpoint MUST <del> terminate a HTTP/2 connection that is opened on a TLS session that </del> <ins> terminate an HTTP/2 connection that is opened on a TLS session that </ins> does not meet these minimum requirements with a ConnectionErrorHandler of type
Code change:
I realize this is somewhat redundant given section 5.1.1, so I don't mind if this pull is rejected. The main reason I think this might be useful is since there are two different stream identifiers involved in PUSHPROMISE: the promised stream id and the stream identifier in the common header. The extra sentence just makes it explicit how PUSHPROMISE is linked to an earlier request. It also puts the following sentence in better context.

Related discussion:
text: The PUSH_PROMISE frame defines the following flags: PUSH_PROMISE frames MUST be associated with an existing, peer- <del> initiated stream.  If the stream identifier field specifies the value 0x0, a recipient MUST respond with a ConnectionErrorHandler of type </del> <ins> initiated stream.  The stream identifier of a PUSH_PROMISE frame indicates the stream it is associated with.  If the stream identifier field specifies the value 0x0, a recipient MUST respond with a ConnectionErrorHandler of type </ins> .
Code change:
I believe that PADLOW and PADHIGH bits in DATA frame were not updated when the dependency based priority was merged. It is quite a headache for implementors if these bits differ across frames.
Yeah, my bad. I missed one.

Related discussion:
text: segment boundary and MUST preserve segment boundaries when forwarding frames. <del> Bit 5 being set indicates that the Pad Low field is present. </del> <ins> Bit 4 being set indicates that the Pad Low field is present. </ins> <del> Bit 6 being set indicates that the Pad High field is present. </del> <ins> Bit 5 being set indicates that the Pad High field is present. </ins> This bit MUST NOT be set unless the PAD_LOW flag is also set. Endpoints that receive a frame with PAD_HIGH set and PAD_LOW cleared MUST treat this as a ConnectionErrorHandler of type
Code change:
I believe that PADLOW and PADHIGH bits in DATA frame were not updated when the dependency based priority was merged. It is quite a headache for implementors if these bits differ across frames.
Yeah, my bad. I missed one.

Related discussion:
text: setting of the peer endpoint is set to 0. <del> The HEADERS frame payload has the following fields: </del> <ins> The PUSH_PROMISE frame payload has the following fields: </ins> Padding size high bits.  This field is only present if the PAD_HIGH flag is set.
Code change:
HTTP/2 has different properties to HTTP/1 regarding server-side load, because load balancers etc. currently exploit HTTP/1's short connections. HTTP/2 has much longer-lived connections, making it more difficult to load balance traffic. A mechanism to direct the client to use a different server/port would mitigate this. While GOAWAY could be used to do this, it introduces latency as the new connection is set up.
Alt-Svc?
URL
NAME is this really in the next milestone? It doesn't seem like we're ready yet.
Should get out a draft momentarily; if we don't make it, that's fine, but if we can, it'd be good to have a bit of discussion first.
NAME this missed the boat. Can I request that you put together something we can discuss in London instead.
Yes, it's on the list for discussion there. The boat technically is delayed at dock...
Discussed in London; agreed to using ALTSVC frame for this.

Related discussion:
text: requests can be highly redundant, so compression can reduce the size of requests and responses significantly. <ins> HTTP/2 also supports HTTP Alternative Services (see AltSvc) using the alt-frame, to allow servers more control over traffic to them. </ins> 2.1. The HTTP/2 specification is split into four parts:
Code change:
HTTP/2 has different properties to HTTP/1 regarding server-side load, because load balancers etc. currently exploit HTTP/1's short connections. HTTP/2 has much longer-lived connections, making it more difficult to load balance traffic. A mechanism to direct the client to use a different server/port would mitigate this. While GOAWAY could be used to do this, it introduces latency as the new connection is set up.
Alt-Svc?
URL
NAME is this really in the next milestone? It doesn't seem like we're ready yet.
Should get out a draft momentarily; if we don't make it, that's fine, but if we can, it'd be good to have a bit of discussion first.
NAME this missed the boat. Can I request that you put together something we can discuss in London instead.
Yes, it's on the list for discussion there. The boat technically is delayed at dock...
Discussed in London; agreed to using ALTSVC frame for this.

Related discussion:
text: The CONTINUATION frame includes optional padding.  Padding fields and flags are identical to those defined for DATA. <ins> 6.11. The ALTSVC frame (type=0xa) advertises the availability of an alternative service to the client.  It can be sent at any time for an existing client-initiated stream or stream 0, and is intended to allow servers to load balance or otherwise segment traffic; see AltSvc for details (in particular, Section 2.4, which outlines client handling of alternative services). An ALTSVC frame on a client-initiated stream indicates that the conveyed alternative service is associated with the origin of that stream. An ALTSVC frame on stream 0 indicates that the conveyed alternative service is associated with the origin contained in the Origin field of the frame.  An association with an origin that the client does not consider authoritative for the current connection MUST be ignored. The ALTSVC frame is intended for receipt by clients; a server that receives an ALTSVC frame MUST treat it as a connection error of type PROTOCOL_ERROR. The ALTSVC frame contains the following fields: PID_LEN: An unsigned, 8-bit integer indicating the length, in bytes, of the PROTOCOL-ID field. Reserved: for future use. Port: An unsigned, 16-bit integer indicating the port that the alternative service is available upon. Max-Age: An unsigned, 32-bit integer indicating the freshness lifetime of the alternative service association, as per AltSvc, Section 2.2. Protocol-ID: A sequence of bytes (length determined by PID_LEN) containing the ALPN protocol identifier of the alternative service. HOST_LEN: An unsigned, 8-bit integer indicating the length, in 8-bit characters, of the Host field. Host: A sequence of characters (length determined by HOST_LEN) containing an ASCII string indicating the host that the alternative service is available upon. Origin: An optional sequence of characters (length determined by ORGN_LEN) containing ASCII serialisation of an origin (RFC6454, Section 6.2) that the alternate service is applicable to. The ALTSVC frame does not define any flags. </ins> 7. Error codes are 32-bit fields that are used in
Code change:
This wording once existed in priority branch in github, but missing in the current draft.

Related discussion:
text: flag is set. An 8-bit weight for the identified priority group, see <del> StreamPriority.  This field is optional and is only present if the </del> <ins> StreamPriority.  Add one to the value to obtain a weight between 1 and 256.  This field is optional and is only present if the </ins> PRIORITY_GROUP flag is set. A single bit flag indicates that the stream dependency is
Code change:
A proposal for adding GZIP compression to DATA frames. One possible resolution for .
This looks good. Thanks for putting this together. We'll see how the discussion progresses.
I realise we might also want to modify Section 8.1.3.5 Malformed Messages, to explain that Content-Length either cannot be sent if any frame is compressed, or measures the length after inflation, depending on how closely this maps to transfer encoding (URL). I suppose that's a follow-up issue for the WG to discuss.
No. You are right. Content-length applies pre-compression or post-decompression. We need to that clear. On Apr 22, 2014 4:28 PM, "Matthew Kerwin" EMAIL wrote:

Related discussion:
text: . <ins> Bit 6 being set indicates that the data in the frame has been compressed with GZIP compression (RFC1952).  The compression only applies to the frame in which it is signalled, and no compression state is carried over from frame to frame.  An endpoint MUST NOT send a DATA frame with the COMPRESSED flag set unless it receives a parameter set to a value of 1.  An endpoint that has not both set this parameter to 1 and had it acknowledged MUST treat the receipt of a DATA frame with the COMPRESSED flag set as a ConnectionErrorHandler of type . </ins> DATA frames MUST be associated with a stream.  If a DATA frame is received whose stream identifier field is 0x0, the recipient MUST respond with a ConnectionErrorHandler of type
Code change:
A proposed explanation for what to do with large header blocks.
Discussed in NYC; this can be considered editorial.

Related discussion:
text: . <ins> 10.5.1. A large HeaderBlock can cause an implementation to commit a large amount of state.  In servers and intermediaries, header fields that are critical to routing, such as ":authority", ":path", and ":scheme" are not guaranteed to be present early in the header block.  In particular, values that are in the reference set cannot be emitted until the header block ends. This can prevent streaming of the header fields to their ultimate destination, and forces the endpoint to buffer the entire header block.  Since there is no hard limit to the size of a header block, an endpoint could be forced to exhaust available memory. A server that receives a larger header block than it is willing to handle can send an HTTP 431 (Request Header Fields Too Large) status code RFC6585.  A client can discard responses that it cannot process. The header block MUST be processed to ensure a consistent connection state, unless the connection is closed. </ins> 10.6. HTTP/2 enables greater use of compression for both header fields
Code change:
... as new priority scheme demands and implies, but does not expressly permit. For .

Related discussion:
text: 6.3. The PRIORITY frame (type=0x2) specifies the StreamPriority.  It can <del> be sent at any time for an existing stream.  This enables reprioritization of existing streams. </del> <ins> be sent at any time for an existing stream, including closed streams. This enables reprioritization of existing streams. </ins> The payload of a PRIORITY frame contains the following fields:
Code change:
... as new priority scheme demands and implies, but does not expressly permit. For .

Related discussion:
text: . The PRIORITY frame can be sent on a stream in any of the "reserved <del> (remote)", "open", "half closed (local)", or "half closed (remote)" states, though it cannot be sent between consecutive frames that comprise a single HeaderBlock.  Note that this frame could arrive after processing or frame sending has completed, which would cause it to have no effect.  For a stream that is in the "half closed (remote)" state, this frame can only affect processing of the stream and not frame transmission. </del> <ins> (remote)", "open", "half closed (local)", "half closed (remote)", or "closed" states, though it cannot be sent between consecutive frames that comprise a single HeaderBlock.  Note that this frame could arrive after processing or frame sending has completed, which would cause it to have no effect on the current stream.  For a stream that is in the "half closed (remote)" or "closed" - state, this frame can only affect processing of the current stream and not frame transmission. The PRIORITY frame is the only frame that can be sent for a closed stream.  This allows for the reprioritization of a group of dependent streams by altering the priority of the parent stream.  However, a PRIORITY frame sent on a closed stream risks being ignored due to the peer having discarded priority state information for that stream. </ins> 6.4.
Code change:
Proposed text for .
This would be consistent with the plan for TLS 1.3.
NAME Firefox hard fails here, which I think is the right decision. I'll confirm with the working group.

Related discussion:
text: therefore likely to be more appropriate for use for performance, security or other reasons. <del> Implementations MUST negotiate - and therefore use - ephemeral cipher suites, such as ephemeral Diffie-Hellman (DHE) or the elliptic curve variant (ECDHE) with a minimum size of 2048 bits (DHE) or security level of 128 bits (ECDHE).  Clients MUST accept DHE sizes of up to 4096 bits. Implementations are encouraged not to negotiate TLS cipher suites with known vulnerabilities, such as RC4. An implementation that negotiates a TLS connection that does not meet the requirements in this section, or any policy-based constraints, SHOULD NOT negotiate HTTP/2.  Removing HTTP/2 protocols from consideration could result in the removal of all protocols from the set of protocols offered by the client.  This causes protocol negotiation failure, as described in TLSALPN. Due to implementation limitations, it might not be possible to fail TLS negotiation based on all of these requirements.  An endpoint MUST terminate an HTTP/2 connection that is opened on a TLS session that does not meet these minimum requirements with a ConnectionErrorHandler of type </del> <ins> The set of TLS cipher suites that are permitted in HTTP/2 is restricted.  HTTP/2 MUST only be used with cipher suites that have ephemeral key exchange, such as the TLS12 or the RFC4492.  Ephemeral key exchange MUST have a minimum size of 2048 bits for DHE or security level of 128 bits for ECDHE.  Clients MUST accept DHE sizes of up to 4096 bits.  HTTP MUST NOT be used with cipher suites that use stream or block ciphers.  Authenticated Encryption with Additional Data (AEAD) modes, such as the RFC5288 are acceptable. Clients MAY advertise support of other cipher suites in order to allow for connection to servers that do not support HTTP/2 to complete without the additional latency imposed by using a separate connection for fallback. An implementation SHOULD NOT negotiate a TLS connection for HTTP/2 without also negotiating a cipher suite that meets these requirements.  Due to implementation limitations, it might not be possible to fail TLS negotiation.  An endpoint MUST immediately terminate an HTTP/2 connection that does not meet these minimum requirements with a ConnectionErrorHandler of type </ins> .