jiebi/CodeConvo huggingface dataset:
Code change:
This leaves only the Capsule Protocol mode
I do think we should add FINAL_DATA, but I'm fine with merging this first and then discussing that in
As of draft-ietf-httpbis-connect-tcp-05, connect-tcp now optionally supports the capsule protocol. However, this optionality adds non-trivial complexity to implementations. As currently written, if a client wishes to use capsules, the server can reject the use of capsules, and now the client needs to cache that this server doesn't support them. However it's undefined for how long the client should cache this information, and within what scope. We could potentially figure out recommendations for all these questions, but fundamentally it might be best to instead make capsules mandatory for connect-tcp, like they are for connect-udp and connect-ip. That would simplify implementations and improve consistency.
Individually, I think it would be interesting to try out this direction — probably based on implementation experience for how easy it is to add. On one hand, this makes connect-tcp less of a trivial drop-in. On the other, it opens up more possible use cases.
I heard a good deal of support for this direction in the HTTPBIS meeting.
Thanks!

Related discussion:
text: "HTTP Capsule Types" registry: For this draft version of the protocol, the Capsule Type value <del> "0xb739a6d0" shall be used provisionally for testing, under the name "DATA-05". </del> <ins> "0x2028d7ee" shall be used provisionally for testing, under the name "DATA-07". </ins>
Code change:
The current text could be interpreted as applying to other HTTP versions, which is not the intent. cc NAME

Related discussion:
text: 7. <del> Clients that send HTTP CONNECT requests on behalf of untrusted TCP clients MUST wait for a 2xx (Successful) response before sending any TCP payload data. </del> <ins> In HTTP/1.1, clients that send CONNECT requests on behalf of untrusted TCP clients MUST wait for a 2xx (Successful) response before sending any TCP payload data. </ins> To mitigate vulnerabilities from any clients that do not conform to this requirement, proxy servers MAY close the underlying connection <del> when rejecting an HTTP CONNECT request, without processing any </del> <ins> when rejecting an HTTP/1.1 CONNECT request, without processing any </ins> further data sent to the proxy server on that connection.  Note that this behavior may impair performance, especially when returning a "407 (Proxy Authentication Required)" response.
Code change:
Adds an example to the Examples section to clarify and illustrate that cookie names are case-sensitive. Additionally adds a clarification that cookie names could be empty to improve readability.
Agreed
What should a user agent do with the "set-cookie-string" ? The current RFC says that the name string can be empty and then in a subsequent step to ignore that cookie. URL
Hi, instructs >If the name-value-pair string lacks a %x3D ("=") character, then the name string is empty, and the value string is the value of name-value-pair. Otherwise, the name string consists of the characters up to, but not including, the first %x3D ("=") character, and the (possibly empty) value string consists of the characters after the first %x3D ("=") character. which covers the case of a nameless cookie such as . I think clarifying, similar to the value string, that the name string could be possibly empty would improve readability, I'll make that change.
Thank you NAME This means there is a change in the recommended parsing algorithm: now empty named cookies are ok. Is that intended?
That's correct. Even though it's strongly not recommended we found that servers still produced unusual set-cookie strings, including empty cookie names, and many UAs accepted them. So the parsing change is meant to standardized behavior so that UAs can at least all do the same thing with them. I still strongly recommend that any sites only use cookies with a non-empty name that conforms to 's syntax. Same for the value field too, now that I'm mentioning it. It'll probably work otherwise, but why make your life harder?
I think the spec would benefit from getting this fact explicitly specified. and are two different cookies.
If you had asked me if this already existed I would have guessed yes. Seems like an obvious improvement
LGTM. It'd be very nice if we could remove the notion of empty cookie names, but since we can't we should document them clearly. :/

Related discussion:
text: the name string is empty, and the value string is the value of name-value-pair. <del> Otherwise, the name string consists of the characters up to, but not including, the first %x3D ("=") character, and the (possibly empty) value string consists of the characters after the first %x3D ("=") character. </del> <ins> Otherwise, the (possibly empty) name string consists of the characters up to, but not including, the first %x3D ("=") character, and the (possibly empty) value string consists of the characters after the first %x3D ("=") character. </ins> Remove any leading or trailing WSP characters from the name string and the value string.
Code change:
If the client gives Upload-Complete=false then the server must respond with Upload-Complete=false and not Upload-Complete=true.
Thank you for this correction!

Related discussion:
text: yet complete indicated by the "Upload-Complete" field value set to false, the server MUST acknowledge it by responding with a "201 (Created)" status code and the "Upload-Complete" field value set to <del> true. </del> <ins> false. </ins> If the request includes the "Upload-Complete" field value set to true and a valid "Content-Length" header field, the client attempts to
Code change:
It's customary to put the terminology and BCP 14 block in the same section, but this works.

Related discussion:
text: 1.1. <ins> This document uses terminology defined in HTTP. 1.2. </ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP
Code change:
NAME thoughts?
Seems fine, with the edits Mark suggested. I'll merge and make those changes unless Paul gets to it first.
Looks pretty good to me, some tweaks here.

Related discussion:
text: Abstract This document describes how "http" URIs can be accessed using <del> Transport Layer Security (TLS) to mitigate pervasive monitoring attacks. </del> <ins> Transport Layer Security (TLS) in HTTP/2 to mitigate pervasive monitoring attacks. </ins> Note to Readers
Code change:
NAME thoughts?
Seems fine, with the edits Mark suggested. I'll merge and make those changes unless Paul gets to it first.
Looks pretty good to me, some tweaks here.

Related discussion:
text: This document describes a use of HTTP Alternative Services RFC7838 to decouple the URI scheme from the use and configuration of underlying <del> encryption, allowing a "http" URI RFC7230 to be accessed using Transport Layer Security (TLS) RFC5246 opportunistically. </del> <ins> encryption.  It allows HTTP/2 RFC7540 to access a "http" URI RFC7230 using Transport Layer Security (TLS) RFC5246 with Opportunistic Security RFC7435. </ins> <del> Serving "https" URIs requires avoiding Mixed Content W3C.CR-mixed- content-20160802, which is problematic in many deployments.  This document describes a usage model whereby sites can serve "http" URIs over TLS, thereby avoiding these issues, while still providing </del> <ins> This document describes a usage model whereby sites can serve "http" URIs over TLS, thereby avoiding the problem of serving Mixed Content (describe in W3C.CR-mixed-content-20160802) while still providing </ins> protection against passive attacks. <del> Opportunistic Security RFC7435 does not provide the same guarantees as using TLS with "https" URIs; it is vulnerable to active attacks, and does not change the security context of the connection. </del> <ins> Opportunistic Security does not provide the same guarantees as using TLS with "https" URIs; Opportunistic Security is vulnerable to active attacks, and does not change the security context of the connection. </ins> Normally, users will not be able to tell that it is in use (i.e., there will be no "lock icon").
Code change:
Related discussions: URL URL
NAME thanks for the review, updated.. ptal.
Thanks!
LGTM

Related discussion:
text: 2.1. <del> Clients control which Client Hint headers and their respective header fields are communicated, based on their default settings, user configuration and/or preferences.  The user can be given the choice to enable, disable, or override specific hints. </del> <ins> Clients control which Client Hints are sent in requests, based on their default settings, user configuration and/or preferences. Implementers might provide user choice mechanisms so that users may balance privacy concerns with bandwidth limitations.  Implementations specific to certain use cases or threat models might avoid transmitting these headers altogether, or limit them to secure contexts or authenticated sessions.  Implementers should be aware that explaining the privacy implications of passive fingerprinting or network information disclosure may be challenging. </ins> The client and server, or an intermediate proxy, can use an opt-in mechanism to negotiate which fields should be reported to allow for
Code change:
Related discussions: URL URL
NAME thanks for the review, updated.. ptal.
Thanks!
LGTM

Related discussion:
text: 6. The "Downlink" request header field is a number that indicates the <del> client's maximum downlink speed in megabits per second (Mbps), as defined by the "downlinkMax" attribute in the W3C Network Information API (NETINFO). </del> <ins> client's maximum downlink speed in megabits per second (Mbps). </ins> If Downlink occurs in a message more than once, the minimum value should be used to override other occurrences.
Code change:
This changes the grammar and text to permit multiple ALPN tokens in the header. This is necessary for HTTP tunnels ("http/1.1" and "h2") as well as some WebRTC cases. I made some editorial changes at the same time. I'll split those out if we don't accept this.

Related discussion:
text: 2. <del> Clients include the Tunnel-Protocol Request Header field in a HTTP Connect request to indicate the application layer protocol or protocols that will be used within the tunnel. </del> <ins> Clients include the `Tunnel-Protocol` Request Header field in an HTTP CONNECT request to indicate the application layer protocol will be used within the tunnel, or the set of protocols that might be used within the tunnel. </ins> 2.1.
Code change:
This changes the grammar and text to permit multiple ALPN tokens in the header. This is necessary for HTTP tunnels ("http/1.1" and "h2") as well as some WebRTC cases. I made some editorial changes at the same time. I'll split those out if we don't accept this.

Related discussion:
text: 2.2. <del> The ABNF (Augmented Backus-Naur Form) syntax for the Tunnel-Protocol header field is given below.  It is based on the Generic Grammar defined in RFC7230. </del> <ins> The ABNF (Augmented Backus-Naur Form) syntax for the `Tunnel- Protocol` header field is given below.  It is based on the Generic Grammar defined in RFC7230. </ins> ALPN protocol names are octet sequences with no additional constraints on format.  Octets not allowed in tokens (RFC7230) must
Code change:
This changes the grammar and text to permit multiple ALPN tokens in the header. This is necessary for HTTP tunnels ("http/1.1" and "h2") as well as some WebRTC cases. I made some editorial changes at the same time. I'll split those out if we don't accept this.

Related discussion:
text: 4. In case of using HTTP CONNECT to a TURN server the security <del> consideration of RFC7231 apply.  It states that there "are </del> <ins> considerations of RFC7231 apply.  It states that there "are </ins> significant risks in establishing a tunnel to arbitrary servers, particularly when the destination is a well-known or reserved TCP port that is not intended for Web traffic.  Proxies that support CONNECT SHOULD restrict its use to a limited set of known ports or a configurable whitelist of safe request targets." <del> The Tunnel-Protocol request header field described in this document is an optional header and HTTP Proxies may of course not support the header and therefore ignore it.  If the header is not present or ignored then the proxy has no explicit indication as to the purpose of the tunnel on which to provide consent, this is the generic case that exists without the Tunnel-Protocol header. </del> <ins> The `Tunnel-Protocol` request header field described in this document is an optional header.  Clients and HTTP Proxies could choose to not support the header and therefore fail to provide it, or ignore it when present.  If the header is not available or ignored, a proxy cannot identify the purpose of the tunnel and use this as input to any authorization decision regarding the tunnel.  This is indistinguishable from the case where either client or proxy does not support the `Tunnel-Protocol` header. </ins>
Code change:
and .
Looks good overall. changes the semantics of . Not only does it effectively put on subsequent responses from the same origin for the given lifetime, it also suggests that Client Hints should be added to requests to that origin, no matter where the requesting page has come from. Not a problem, but right now it's conveyed almost as an aside. This needs to be clearly specified so it isn't missed / misunderstood.
NAME updated, PTAL.
Thanks Mark!
This is better.

Related discussion:
text: 2.2. When presented with a request that contains one or more client hint <del> headers, servers can optimise the response based upon the information </del> <ins> headers, servers can optimize the response based upon the information </ins> in them.  When doing so, and if the resource is cacheable, the server MUST also generate a Vary response header field (Section 7.1.4 of RFC7231), and optionally Key (I-D.ietf-httpbis-key), to indicate
Code change:
and .
Looks good overall. changes the semantics of . Not only does it effectively put on subsequent responses from the same origin for the given lifetime, it also suggests that Client Hints should be added to requests to that origin, no matter where the requesting page has come from. Not a problem, but right now it's conveyed almost as an aside. This needs to be clearly specified so it isn't missed / misunderstood.
NAME updated, PTAL.
Thanks Mark!
This is better.

Related discussion:
text: When a client receives Accept-CH, or if it is capable of processing the HTML response and finds an equivalent HTML meta element, it can <del> treat it as a signal that the server is interested in receiving </del> <ins> treat it as a signal that the application is interested in receiving </ins> specified request header fields that match the advertised field- <del> values; subsequent requests initiated to the same server and, optionally any subresource requests initiated as a result of processing the response from the server that includes the Accept-CH opt-in, can include the request header fields that match the advertised field-values. </del> <ins> values; subresource requests initiated as a result of processing the response from the server that includes the Accept-CH opt-in can include the request header fields that match the advertised field- values. </ins> For example, based on Accept-CH example above, a user agent could <del> append DPR, Width, Viewport-Width, and Downlink header fields to all </del> <ins> append DPR, Width, and Viewport-Width header fields to all </ins> subresource requests initiated by the page constructed from the <del> response.  Alternatively, a client can treat advertised support as a persistent origin preference and append same header fields on all future requests initiated to and by the resources associated with that origin. </del> <ins> response. </ins> 2.2.2. <ins> Servers can ask the client to remember an origin-wide Accept-CH preference for a specified period of time to enable delivery of Client Hints on all subsequent requests to the origin, and on subresource requests initiated as a result of processing a response from the origin. The field-value indicates that the Accept-CH preference should be considered stale after its age is greater than the specified number of seconds. For example, based on the Accept-CH and Accept-CH-Lifetime example above, a user agent could persist an origin-wide Accept-CH preference for up to 86400 seconds (1 day).  Then, if a request is initiated to the same origin before the preference is stale (e.g. as a result of a navigation to the origin, or fetching a subresource from the origin) the client could append the requested header fields (DPR and Viewport-Width in this example) to the request and any subresource requests initiated as a result of processing a response from same origin. 2.2.3. </ins> When selecting an optimized response based on one or more Client Hints, and if the resource is cacheable, the server needs to generate a Vary response header field (RFC7234) to indicate which hints can
Code change:
and .
Looks good overall. changes the semantics of . Not only does it effectively put on subsequent responses from the same origin for the given lifetime, it also suggests that Client Hints should be added to requests to that origin, no matter where the requesting page has come from. Not a problem, but right now it's conveyed almost as an aside. This needs to be clearly specified so it isn't missed / misunderstood.
NAME updated, PTAL.
Thanks Mark!
This is better.

Related discussion:
text: Implementers ought to provide mechanisms and policies to control how and when such hints are advertised.  For example, they could require <del> origin opt-in; restrict delivery to same origin subrequests; limit delivery to requests that already carry indentifying information (e.g. cookies); modify delivery policy when in an "incognito" or a similar privacy mode; enable user configuration and opt in, and so on. </del> <ins> origin opt-in via Accept-CH; clear remembered opt-in, as set by Accept-CH-Lifetime, when site data, browsing history, browsing cache, or similar, are cleared; restrict delivery to same origin subrequests; limit delivery to requests that already carry identifying information (e.g. cookies); modify delivery policy when in an "incognito" or a similar privacy mode; enable user configuration and opt in, and so on. </ins> 6.
Code change:
and .
Looks good overall. changes the semantics of . Not only does it effectively put on subsequent responses from the same origin for the given lifetime, it also suggests that Client Hints should be added to requests to that origin, no matter where the requesting page has come from. Not a problem, but right now it's conveyed almost as an aside. This needs to be clearly specified so it isn't missed / misunderstood.
NAME updated, PTAL.
Thanks Mark!
This is better.

Related discussion:
text: 6.2. <ins> Header field name: Accept-CH-Lifetime Applicable protocol: HTTP Status: standard Author/Change controller: IETF Specification document(s): accept-ch-lifetime of this document Related information: for Client Hints 6.3. </ins> Header field name: Content-DPR Applicable protocol: HTTP Status: standard
Code change:
and .
Looks good overall. changes the semantics of . Not only does it effectively put on subsequent responses from the same origin for the given lifetime, it also suggests that Client Hints should be added to requests to that origin, no matter where the requesting page has come from. Not a problem, but right now it's conveyed almost as an aside. This needs to be clearly specified so it isn't missed / misunderstood.
NAME updated, PTAL.
Thanks Mark!
This is better.

Related discussion:
text: Specification document(s): content-dpr of this document Related information: for Client Hints <del> 6.3. </del> <ins> 6.4. </ins> Header field name: Downlink Applicable protocol: HTTP
Code change:
and .
Looks good overall. changes the semantics of . Not only does it effectively put on subsequent responses from the same origin for the given lifetime, it also suggests that Client Hints should be added to requests to that origin, no matter where the requesting page has come from. Not a problem, but right now it's conveyed almost as an aside. This needs to be clearly specified so it isn't missed / misunderstood.
NAME updated, PTAL.
Thanks Mark!
This is better.

Related discussion:
text: Specification document(s): downlink of this document Related information: for Client Hints <del> 6.4. </del> <ins> 6.5. </ins> Header field name: DPR Applicable protocol: HTTP
Code change:
and .
Looks good overall. changes the semantics of . Not only does it effectively put on subsequent responses from the same origin for the given lifetime, it also suggests that Client Hints should be added to requests to that origin, no matter where the requesting page has come from. Not a problem, but right now it's conveyed almost as an aside. This needs to be clearly specified so it isn't missed / misunderstood.
NAME updated, PTAL.
Thanks Mark!
This is better.

Related discussion:
text: Specification document(s): dpr of this document Related information: for Client Hints <del> 6.5. </del> <ins> 6.6. </ins> Header field name: Save-Data Applicable protocol: HTTP
Code change:
and .
Looks good overall. changes the semantics of . Not only does it effectively put on subsequent responses from the same origin for the given lifetime, it also suggests that Client Hints should be added to requests to that origin, no matter where the requesting page has come from. Not a problem, but right now it's conveyed almost as an aside. This needs to be clearly specified so it isn't missed / misunderstood.
NAME updated, PTAL.
Thanks Mark!
This is better.

Related discussion:
text: Specification document(s): save-data of this document Related information: for Client Hints <del> 6.6. </del> <ins> 6.7. </ins> Header field name: Viewport-Width Applicable protocol: HTTP
Code change:
and .
Looks good overall. changes the semantics of . Not only does it effectively put on subsequent responses from the same origin for the given lifetime, it also suggests that Client Hints should be added to requests to that origin, no matter where the requesting page has come from. Not a problem, but right now it's conveyed almost as an aside. This needs to be clearly specified so it isn't missed / misunderstood.
NAME updated, PTAL.
Thanks Mark!
This is better.

Related discussion:
text: Specification document(s): viewport-width of this document Related information: for Client Hints <del> 6.7. </del> <ins> 6.8. </ins> Header field name: Width Applicable protocol: HTTP
Code change:
While testing firefox's implementation of this draft Vlad determined that some versions of Chrome throw PROTOCOL_ERROR and close the connection if it receives a type 0xB frame with a non zero length on stream 0. Other frame type numbers, such as 0xC do not seem to have that problem. testing indicates this is fixed in version 59 and is a problem previous to that. (57 is in release as I write this). presumably this is related to historical code around BLOCKED which was proposed to use 0xB. Prudence says to just use a different code point for the moment.
Question for NAME and NAME should we somehow reserve 0xb to avoid this problem?
If this is fixed in Chrome 59, why bother? Actually, I'd also revert this change.
Neither. There are still old Chrome versions deployed (some people lag, for various reasons), so it's not safe to use now, but it should be in the not-to-distant future; we just need to wait a while to use it (presumably for another extension). Reserving it for all time would be a bad precedent.

Related discussion:
text: 2.1. <del> The ORIGIN frame type is 0xb (decimal 11). </del> <ins> The ORIGIN frame type is 0xc (decimal 12). </ins> The ORIGIN frame's payload contains the following fields, sets of which may be repeated within the frame to indicate multiple origins: