jiebi/CodeConvo huggingface dataset:
Code change:
HTTP/2 requires clients to support the gzip content-coding. The justification for this has always been that it helps avoid intermediaries and other interposed software (e.g., virus filters) that strip Accept-Encoding to avoid the pain of decompressing responses. However, it has been pointed out that doing so means that intermediaries that translate from 1 to 2 are now required to synthesise new entity tags for decompressed responses, breaking semantic transparency and/or losing significant HTTP functionality.
See also .
It also requires to rewrite ETags in request headers (conditional ones), which is an open-ended list. Furthermore, ETags also appear in payloads (WebDAV properties, for instance).
The outcome of this issue also affects
Discussed in NYC; will remove implicit gzip from spec; may create new content-coding required status code or other strategy (non-blocking).

Related discussion:
text: . <del> 9.3. Clients MUST support GZIP compression for HTTP response bodies. Regardless of the value of the accept-encoding header field, a server MAY send responses with GZIP encoding.  A compressed response MUST still bear an appropriate content-encoding header field. This effectively changes the implicit value of the Accept-Encoding header field (HTTP-p2) from "identity" to "identity, gzip", however GZIP encoding cannot be suppressed by including ";q=0". Intermediaries that perform translation from HTTP/2 to HTTP/1.1 MUST decompress payloads unless the request includes an Accept-Encoding value that includes "gzip". </del> 10. 10.1.
Code change:
Frames can be coalesced or split -- this is antagonistic to end-to-end, per-frame compression. This requires decompression / recompression in proxies that need to coalesce or split frame.
Discussed in NYC; no implementer interest, security concerns about proxying it. We believe it can be addressed as an extension now if someone wants to scratch that itch (and can find someone to interop with); however, fixing this properly means doing it at the HTTP semantic layer (e.g., with a new range type). In the meantime, remove frame compression.

Related discussion:
text: Bit 4 being set indicates that the Pad Length field is present. <del> Bit 6 being set indicates that the data in the frame has been compressed with GZIP compression (GZIP).  Padding is not compressed. </del> 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 . <del> Data frames are optionally compressed using GZIP.  Each frame is individually compressed; the state of the compressor is reset for each frame. An endpoint MUST NOT send a DATA frame with the COMPRESSED flag set unless the setting is enabled, that is, set to 1.  An endpoint that has not enabled DATA frame compression MUST treat the receipt of a DATA frame with the COMPRESSED flag set as a ConnectionErrorHandler of type . </del> DATA frames are subject to flow control and can only be sent when a stream is in the "open" or "half closed (remote)" states.  The entire DATA frame payload is included in flow control, including Pad Low,
Code change:
Two minor things here: more strongly recommend the use of the frame type in HTTP/2 over the header field add a frame type number (no need to defer the choice now, this lets people build code based on this)

Related discussion:
text: instead send an ALTSVC frame.  A single ALTSVC frame can be sent for a connection; a new frame is not required for every request. <ins> When using HTTP2, clients SHOULD instead send an ALTSVC frame.  A single ALTSVC frame can be sent for a connection; a new frame is not required for every request. </ins> 3.1. When an alternative service is advertised using Alt-Svc, it is
Code change:
Two minor things here: more strongly recommend the use of the frame type in HTTP/2 over the header field add a frame type number (no need to defer the choice now, this lets people build code based on this)

Related discussion:
text: be ignored. <ins> The ALTSVC frame type is 0xa (decimal 10). </ins> The ALTSVC frame contains the following fields: An unsigned, 32-bit integer indicating the freshness lifetime of
Code change:
I have written what I think is a slightly more robust Security Consideration for HPACK. This covers: the attack in the general sense, how the attack might apply in HPACK and HTTP, particular areas of concern, how HPACK inherently mitigates these attacks, what environments might need additional mitigation, and some suggested mitigation strategies. Mitigation strategies that I have described are: actor-based isolation (a generalized application of the origin isolation principle) destroy values on failed guesses (thanks here to Adam Barth for the idea), either probabilistically, or based on a count, with a recommendation that shorter values be made harder to guess specific protection for "special" header fields There are a few formatting changes in the first commit, sorry.

Related discussion:
text: 7.2.3. A literal header field never indexed representation causes the <del> emission of a header field without altering the header table.  It requires intermediaries to use the same representation for encoding this header field. </del> <ins> emission of a header field without altering the header table. Intermediaries MUST use the same representation for encoding this header field. </ins> A literal header field never indexed representation starts with the '0001' 4-bit pattern.
Code change:
I have written what I think is a slightly more robust Security Consideration for HPACK. This covers: the attack in the general sense, how the attack might apply in HPACK and HTTP, particular areas of concern, how HPACK inherently mitigates these attacks, what environments might need additional mitigation, and some suggested mitigation strategies. Mitigation strategies that I have described are: actor-based isolation (a generalized application of the origin isolation principle) destroy values on failed guesses (thanks here to Adam Barth for the idea), either probabilistically, or based on a count, with a recommendation that shorter values be made harder to guess specific protection for "special" header fields There are a few formatting changes in the first commit, sorry.

Related discussion:
text: information leakage to recover any meaningful amount of information (see PETAL). <del> 8.2. </del> <ins> 8.3. </ins> An attacker can try to cause an endpoint to exhaust its memory. HPACK is designed to limit both the peak and state amounts of memory
Code change:
I have written what I think is a slightly more robust Security Consideration for HPACK. This covers: the attack in the general sense, how the attack might apply in HPACK and HTTP, particular areas of concern, how HPACK inherently mitigates these attacks, what environments might need additional mitigation, and some suggested mitigation strategies. Mitigation strategies that I have described are: actor-based isolation (a generalized application of the origin isolation principle) destroy values on failed guesses (thanks here to Adam Barth for the idea), either probabilistically, or based on a count, with a recommendation that shorter values be made harder to guess specific protection for "special" header fields There are a few formatting changes in the first commit, sorry.

Related discussion:
text: does not force this to occur, application constraints might make this necessary. <del> 8.3. </del> <ins> 8.4. </ins> An implementation of HPACK needs to ensure that large values for integers, long encoding for integers, or long string literals do not
Code change:
Two small changes here. First, adding unnegotiated semantics to reserved bits in existing frames feels like a REALLY bad idea, since you're almost guaranteed to have collisions, so I'm suggesting we remove that as something that extensions can do unannounced. Second, we permit negotiated changes to existing semantics, so I'm suggesting that instead of saying only DATA will ever be flow controlled, we say that making anything else flow-controlled is a changed semantic that has to be negotiated.
(And as a side-note, section 6.9 implies that there may be frames other than DATA which are flow-controlled defined elsewhere: "Flow control only applies to frames that are identified as being subject to flow control. Of the frame types defined in this document, this includes only DATA frame.")

Related discussion:
text: connection. Extensions are permitted to use new FrameHeader, SettingValues, <del> ErrorCodes, header fields that start with a colon (:), or any reserved flags or fields in frames.  Of these, registries are established for iana-frames, iana-settings and iana-errors. </del> <ins> ErrorCodes, or header fields that start with a colon (:).  Of these, registries are established for iana-frames, iana-settings and iana- errors. </ins> Implementations MUST ignore unknown or unsupported values in all extensible protocol elements.  Implementations MUST discard frames <del> that have unknown or unsupported types.  Note that only frames can be flow controlled, extensions cannot be flow controlled. This means that any of these extension points can be safely used by extensions without prior arrangement or negotiation. </del> <ins> that have unknown or unsupported types.  This means that any of these extension points can be safely used by extensions without prior arrangement or negotiation. </ins> However, extensions can negotiate any use that could change to the semantics of existing protocol components.  For example, an extension
Code change:
Two small changes here. First, adding unnegotiated semantics to reserved bits in existing frames feels like a REALLY bad idea, since you're almost guaranteed to have collisions, so I'm suggesting we remove that as something that extensions can do unannounced. Second, we permit negotiated changes to existing semantics, so I'm suggesting that instead of saying only DATA will ever be flow controlled, we say that making anything else flow-controlled is a changed semantic that has to be negotiated.
(And as a side-note, section 6.9 implies that there may be frames other than DATA which are flow-controlled defined elsewhere: "Flow control only applies to frames that are identified as being subject to flow control. Of the frame types defined in this document, this includes only DATA frame.")

Related discussion:
text: frame cannot be used until the peer has given a positive signal that this is acceptable.  In this case, it could also be necessary to <del> coordinate when the revised layout comes into effect. </del> <ins> coordinate when the revised layout comes into effect.  Note that treating any frame other than frames as flow controlled is such a change in semantics, and can only be done through negotiation. </ins> This document doesn't mandate a specific method for negotiating the use of an extension, but notes that a SettingValues could be used for
Code change:
Mostly minor stuff from a readthrough. Of particular note: Regarding headers, "name-value pair" implies only one value; either it's a pair, and collections may have multiple instances with the same name; or it's a name with a collection of associated values. Either is reasonable, but both is confusing. Adjusting phrasing in SETTINGSHEADERTABLE_SIZE to better reflect that HPACK now lets the encoder change the table size at will. Removing suggestion that a GOAWAY frame can get "lost", which can't happen in TCP; actual issue is that recipient may have acted on the previous GOAWAY and retried the requests the server says it didn't process.

Related discussion:
text: 4.3. <del> A header field in HTTP/2 is a name-value pair with one or more associated values.  They are used within HTTP request and response messages as well as server push operations (see PushResources). </del> <ins> A header field in HTTP/2 is a name with one or more associated values.  They are used within HTTP request and response messages as well as server push operations (see PushResources). </ins> Header sets are collections of zero or more header fields.  When transmitted over a connection, a header set is serialized into a
Code change:
Mostly minor stuff from a readthrough. Of particular note: Regarding headers, "name-value pair" implies only one value; either it's a pair, and collections may have multiple instances with the same name; or it's a name with a collection of associated values. Either is reasonable, but both is confusing. Adjusting phrasing in SETTINGSHEADERTABLE_SIZE to better reflect that HPACK now lets the encoder change the table size at will. Removing suggestion that a GOAWAY frame can get "lost", which can't happen in TCP; actual issue is that recipient may have acted on the previous GOAWAY and retried the requests the server says it didn't process.

Related discussion:
text: Stream identifiers cannot be reused.  Long-lived connections can result in an endpoint exhausting the available range of stream identifiers.  A client that is unable to establish a new stream <del> identifier can establish a new connection for new streams. </del> <ins> identifier can establish a new connection for new streams.  A server that is unable to establish a new stream identifier may send a frame to require the client to establish a new connection. </ins> 5.1.2.
Code change:
Mostly minor stuff from a readthrough. Of particular note: Regarding headers, "name-value pair" implies only one value; either it's a pair, and collections may have multiple instances with the same name; or it's a name with a collection of associated values. Either is reasonable, but both is confusing. Adjusting phrasing in SETTINGSHEADERTABLE_SIZE to better reflect that HPACK now lets the encoder change the table size at will. Removing suggestion that a GOAWAY frame can get "lost", which can't happen in TCP; actual issue is that recipient may have acted on the previous GOAWAY and retried the requests the server says it didn't process.

Related discussion:
text: permitted to open.  Streams in any of these three states count toward the limit advertised in the <del> setting. </del> <ins> setting.  Streams in either of the "reserved" states do not count as open. </ins> Endpoints MUST NOT exceed the limit set by their peer.  An endpoint that receives a
Code change:
Mostly minor stuff from a readthrough. Of particular note: Regarding headers, "name-value pair" implies only one value; either it's a pair, and collections may have multiple instances with the same name; or it's a name with a collection of associated values. Either is reasonable, but both is confusing. Adjusting phrasing in SETTINGSHEADERTABLE_SIZE to better reflect that HPACK now lets the encoder change the table size at will. Removing suggestion that a GOAWAY frame can get "lost", which can't happen in TCP; actual issue is that recipient may have acted on the previous GOAWAY and retried the requests the server says it didn't process.

Related discussion:
text: frame that causes their advertised concurrent stream limit to be exceeded MUST treat this as a StreamErrorHandler. <del> Streams in either of the "reserved" states do not count as open. </del> 5.2. Using streams for multiplexing introduces contention over use of the
Code change:
Mostly minor stuff from a readthrough. Of particular note: Regarding headers, "name-value pair" implies only one value; either it's a pair, and collections may have multiple instances with the same name; or it's a name with a collection of associated values. Either is reasonable, but both is confusing. Adjusting phrasing in SETTINGSHEADERTABLE_SIZE to better reflect that HPACK now lets the encoder change the table size at will. Removing suggestion that a GOAWAY frame can get "lost", which can't happen in TCP; actual issue is that recipient may have acted on the previous GOAWAY and retried the requests the server says it didn't process.

Related discussion:
text: prioritization, since the stream could be given a priority that is higher than intended. <del> To avoid these problems, endpoints SHOULD maintain prioritization state for closed streams for a period after streams close. An endpoint SHOULD retain stream prioritization state for a period after streams become closed.  The longer state is retained, the lower the chance that streams are assigned incorrect or default priority values. </del> <ins> To avoid these problems, an endpoint SHOULD retain stream prioritization state for a period after streams become closed.  The longer state is retained, the lower the chance that streams are assigned incorrect or default priority values. </ins> This could create a large state burden for an endpoint, so this state MAY be limited.  An endpoint MAY apply a fixed upper limit on the
Code change:
Mostly minor stuff from a readthrough. Of particular note: Regarding headers, "name-value pair" implies only one value; either it's a pair, and collections may have multiple instances with the same name; or it's a name with a collection of associated values. Either is reasonable, but both is confusing. Adjusting phrasing in SETTINGSHEADERTABLE_SIZE to better reflect that HPACK now lets the encoder change the table size at will. Removing suggestion that a GOAWAY frame can get "lost", which can't happen in TCP; actual issue is that recipient may have acted on the previous GOAWAY and retried the requests the server says it didn't process.

Related discussion:
text: that requires immediate termination of the connection.  The last stream identifier from the last GOAWAY frame received indicates which streams could have been acted upon.  Endpoints MUST NOT increase the <del> value they send in the last stream identifier, since this could cause their peers to erroneously retry streams if a GOAWAY frame is lost. </del> <ins> value they send in the last stream identifier, since the peers might already have retried unprocessed requests on another connection. </ins> A client that is unable to retry requests loses all requests that are in flight when the server closes the connection.  This is especially
Code change:
Mostly minor stuff from a readthrough. Of particular note: Regarding headers, "name-value pair" implies only one value; either it's a pair, and collections may have multiple instances with the same name; or it's a name with a collection of associated values. Either is reasonable, but both is confusing. Adjusting phrasing in SETTINGSHEADERTABLE_SIZE to better reflect that HPACK now lets the encoder change the table size at will. Removing suggestion that a GOAWAY frame can get "lost", which can't happen in TCP; actual issue is that recipient may have acted on the previous GOAWAY and retried the requests the server says it didn't process.

Related discussion:
text: subject to flow control.  Of the frame types defined in this document, this includes only <del> frame.  Frames that are exempt from flow control MUST be accepted and processed, unless the receiver is unable to assign resources to </del> <ins> frames.  Frames that are exempt from flow control MUST be accepted and processed, unless the receiver is unable to assign resources to </ins> handling the frame.  A receiver MAY respond with a StreamErrorHandler or ConnectionErrorHandler of type
Code change:
Could have been "a" just as easily, but I felt like a two-character pull request was just overkill.

Related discussion:
text: A server that does not wish clients to reuse connections can indicate that it is not authoritative for a request by sending a 421 (Not <del> Authoritative) status code in response to request (see </del> <ins> Authoritative) status code in response to the request (see </ins> NotAuthoritative). 9.1.2.
Code change:
Note: adds downref to Informational spec.
It has been noted that there is an opportunity for interoperability failure with the rules we have regarding ephemeral key exchange. e.g., client has only DHE, server has only ECDHE, can't use HTTP/2 Do we want to specify a mandatory to implement cipher suite so that we can avoid this?
Yes, I think you do. TLS 1.3 will be mandating ephemeral key exchange, so I think you just want to use whatever their MTI is (presumably either DHE or ECDHE with AES-GCM). I expect to have a preliminary answer to this in YVR. Will that be soon enough?
TOR, I hope. But I think that should suffice. We can discuss whether we try to preempt that decision or leave a placeholder.
Sorry, I meant YYZ.
Discussed in NYC; will make a decision about it in Toronto. Under discussion - ECDHE / DHE + RSA + AES-GCM + SHA256. Maybe another too.
We need to settle this for WGLC. NAME any chance of getting a decision earlier?
is editor-ready.

Related discussion:
text: 3.3. A client that makes a request to an "https" URI without prior <del> knowledge about support for HTTP/2 uses TLS12 with the TLSALPN. </del> <ins> knowledge about support for HTTP/2 uses TLS12 with the TLS-ALPN. </ins> HTTP/2 over TLS uses the "h2" application token.  The "h2c" token MUST NOT be sent by a client or selected by a server.
Code change:
Note: adds downref to Informational spec.
It has been noted that there is an opportunity for interoperability failure with the rules we have regarding ephemeral key exchange. e.g., client has only DHE, server has only ECDHE, can't use HTTP/2 Do we want to specify a mandatory to implement cipher suite so that we can avoid this?
Yes, I think you do. TLS 1.3 will be mandating ephemeral key exchange, so I think you just want to use whatever their MTI is (presumably either DHE or ECDHE with AES-GCM). I expect to have a preliminary answer to this in YVR. Will that be soon enough?
TOR, I hope. But I think that should suffice. We can discuss whether we try to preempt that decision or leave a placeholder.
Sorry, I meant YYZ.
Discussed in NYC; will make a decision about it in Toronto. Under discussion - ECDHE / DHE + RSA + AES-GCM + SHA256. Maybe another too.
We need to settle this for WGLC. NAME any chance of getting a decision earlier?
is editor-ready.

Related discussion:
text: such a connection by the use of the "PRI" method in the connection preface.  This only affects the establishment of HTTP/2 connections over cleartext TCP; implementations that support HTTP/2 over TLS MUST <del> use TLSALPN. </del> <ins> use TLS-ALPN. </ins> Prior support for HTTP/2 is not a strong signal that a given server will support HTTP/2 for future connections.  It is possible for