jiebi/CodeConvo huggingface dataset:
Code change:
Closes URL NAME mind taking a look?
(NAME would you mind adding NAME to the repo as a collaborator so I can ask him to review via the GitHub tool? :) )
Ping.
Invite was sent a while back. Still listed as "pending."
It is an internal flag, but I don't think the PR needs additional documentation. The change we're making is in the middle of an algorithm, and is basically a variable that was set earlier in the process. I think folks reading the document will understand that. :)
Thanks for the review! I'll merge this, and look forward to your PR adding yourself as an editor.
RFC 6265 section 5.3 defines a cookie by the name, domain, and path. However, given these two headers in a response from a request to URL Set-Cookie: mycookie=nothostonly; URL Set-Cookie: mycookie=hostonly Most browsers will have two cookies since they include host-only-flag in their definition of a unique cookie. I'd like to update section 4.1.2 and 5.3 to reflect the behavior of modern browsers with regards to host-only-flag.
Discussed in Berlin; seems reasonable.
I probably need to read more of the context but would it be useful to point out that this is an internal flag for the user agent? It is, right? Inferred from whether the setting of the cookie included the domain or not.

Related discussion:
text: attribute-name of "Path", and the cookie's path is "/". If the cookie store contains a cookie with the same name, domain, <del> and path as the newly-created cookie: </del> <ins> host-only-flag, and path as the newly-created cookie: </ins> Let old-cookie be the existing cookie with the same name, <del> domain, and path as the newly-created cookie.  (Notice that this algorithm maintains the invariant that there is at most one such cookie.) </del> <ins> domain, host-only-flag, and path as the newly-created cookie. (Notice that this algorithm maintains the invariant that there is at most one such cookie.) </ins> If the newly-created cookie was received from a "non-HTTP" API and the old-cookie's http-only-flag is true, abort these steps
Code change:
For
from the list Maybe we should be talking about a Variant-Key syntax that lets you specify alternative sets of values, e.g.,

Related discussion:
text: values from the Variants header field that identify the representation it occurs within. <del> Each member of the list contains the selected available-value(s), in the same order as the variants listed in the Variants header field. </del> <ins> Each member of the list contains a set of selected available-value(s) that identify this representation, in the same order as the variants listed in the Variants header field. </ins> <del> Therefore, Variant-Key MUST be the same length (in comma-separated members) as Variants, and each member MUST correspond in position to its companion in Variants. </del> <ins> Therefore, each member of Variant-Key MUST be the same length (in semicolon-separated members) as Variants, and each member's available-values MUST correspond in position to their companions in Variants. </ins> For example: This header pair indicates that the representation has a "gzip" content-coding and "fr" content-language. <del> A more complex example involves listing multiple available-values in a list member, to indicate that the response can be used to satisfy requests with any of those values.  For example: </del> <ins> If the response can be used to satisfy more than one request), they can be listed in additional members.  For example: </ins> indicates that this response can be used for requests whose Accept- Encoding algorithm selects "gzip" or "identity", as long as the Accept-Language algorithm selects "fr" - perhaps because there is no gzip-compressed French representation. <del> This highlights an important aspect of Variant-Key; it is only used to indicate what request attributes are associated with the response containing it; this is different from headers like Content-Encoding, which indicate attributes of the response itself. </del> <ins> When more than one Variant-Key value is in a response, the first one present MUST indicate the variant-key for the response it occurs within. </ins> 3.1.
Code change:
For
from the list Maybe we should be talking about a Variant-Key syntax that lets you specify alternative sets of values, e.g.,

Related discussion:
text: Remove all whitespace from value. <del> Let items be the result of splitting value on ";". </del> <ins> Append value to variant-keys. </ins> <del> append items to variant-keys. Return the result of running Compute Possible Keys (find) on variant-keys, an empty string and an empty list. </del> <ins> Return variant-keys. </ins> 4.
Code change:
Takes a dependency on URL
I think that it would be better to explicitly reference CERTIFICATE_REQUEST in the cases where a CERTIFICATE is generated directly in response to one. Using the "get context" API from exported authenticators is ugly. This is more important now that exported authenticators folds the request into the response. We probably want to use a flag for whether this is spontaneous so that we can avoid reserving a Request-ID for spontaneous CERTIFICATE messages.
I'm a little dubious about this. Having the same value transported in two different fields and then checking that they're equal seems potentially more error-prone than just transporting it in one place, even if that one place is by calling into a library to interpret for you.
For posterity, discussion in Montreal: Nice not to have to dig out the Request-ID. However, if you duplicate it, then you have to compare and check that they're equal, so you're still calling into TLS. There is an existing duplication in the CERTIFICATE_REQUEST, where the Request-ID is carried outside the EA.

Related discussion:
text: both the two-octet Request-ID as well as at least 96 bits of additional entropy. <ins> Upon receipt of a "CERTIFICATE_REQUEST" frame, the recipient MUST verify that the first two octets of the authenticator's "certificate_request_context" matches the Request-ID presented in the frame. </ins> The TLS library on the authenticating peer will provide mechanisms to select an appropriate certificate to respond to the transported request.  TLS libraries on servers MUST be able to recognize the
Code change:
Takes a dependency on URL
I think that it would be better to explicitly reference CERTIFICATE_REQUEST in the cases where a CERTIFICATE is generated directly in response to one. Using the "get context" API from exported authenticators is ugly. This is more important now that exported authenticators folds the request into the response. We probably want to use a flag for whether this is spontaneous so that we can avoid reserving a Request-ID for spontaneous CERTIFICATE messages.
I'm a little dubious about this. Having the same value transported in two different fields and then checking that they're equal seems potentially more error-prone than just transporting it in one place, even if that one place is by calling into a library to interpret for you.
For posterity, discussion in Montreal: Nice not to have to dig out the Request-ID. However, if you duplicate it, then you have to compare and check that they're equal, so you're still calling into TLS. There is an existing duplication in the CERTIFICATE_REQUEST, where the Request-ID is carried outside the EA.

Related discussion:
text: Indicates that the exported authenticator spans more than one frame. <ins> Indicates that the exported authenticator does not contain a Request-ID. </ins> The frame contains the following fields: "Cert-ID" is a 16-bit opaque identifier used to correlate other certificate- related frames with this exported authenticator fragment. <ins> "Request-ID" is an optional 16-bit opaque identifier used to correlate this exported authenticator with the request which triggered it, if any.  This field is present only if the "UNSOLICITED" flag is not set. </ins> A portion of the opaque data returned from the TLS connection exported authenticator "authenticate" API.  See exp-auth for more details on the input to this API.
Code change:
Takes a dependency on URL
I think that it would be better to explicitly reference CERTIFICATE_REQUEST in the cases where a CERTIFICATE is generated directly in response to one. Using the "get context" API from exported authenticators is ugly. This is more important now that exported authenticators folds the request into the response. We probably want to use a flag for whether this is spontaneous so that we can avoid reserving a Request-ID for spontaneous CERTIFICATE messages.
I'm a little dubious about this. Having the same value transported in two different fields and then checking that they're equal seems potentially more error-prone than just transporting it in one place, even if that one place is by calling into a library to interpret for you.
For posterity, discussion in Montreal: Nice not to have to dig out the Request-ID. However, if you duplicate it, then you have to compare and check that they're equal, so you're still calling into TLS. There is an existing duplication in the CERTIFICATE_REQUEST, where the Request-ID is carried outside the EA.

Related discussion:
text: frame with "TO_BE_CONTINUED" unset MUST be treated as a connection error of type "PROTOCOL_ERROR". <ins> If the "UNSOLICITED" flag is not set, the "CERTIFICATE" frame also contains a Request-ID indicating the certificate request which caused this exported authenticator to be generated.  The value of this flag and the contents of the Request-ID field MUST NOT differ between frames with the same Cert-ID. </ins> Upon receiving a complete series of "CERTIFICATE" frames, the receiver may validate the Exported Authenticator value by using the exported authenticator API.  This returns either an error indicating
Code change:
Takes a dependency on URL
I think that it would be better to explicitly reference CERTIFICATE_REQUEST in the cases where a CERTIFICATE is generated directly in response to one. Using the "get context" API from exported authenticators is ugly. This is more important now that exported authenticators folds the request into the response. We probably want to use a flag for whether this is spontaneous so that we can avoid reserving a Request-ID for spontaneous CERTIFICATE messages.
I'm a little dubious about this. Having the same value transported in two different fields and then checking that they're equal seems potentially more error-prone than just transporting it in one place, even if that one place is by calling into a library to interpret for you.
For posterity, discussion in Montreal: Nice not to have to dig out the Request-ID. However, if you duplicate it, then you have to compare and check that they're equal, so you're still calling into TLS. There is an existing duplication in the CERTIFICATE_REQUEST, where the Request-ID is carried outside the EA.

Related discussion:
text: Upon receipt of a "CERTIFICATE" frame, an endpoint MUST perform the following steps to validate the token it contains: <ins> Verify that either the "UNSOLICITED" flag is set (clients only) or that the Request-ID field contains the Request-ID of a previously- sent "CERTIFICATE_REQUEST" frame. </ins> Using the "get context" API, retrieve the "certificate_request_context" used to generate the authenticator, <del> if any. Verify that the "certificate_request_context" is either empty (clients only) or contains the Request-ID of a previously-sent "CERTIFICATE_REQUEST" frame. </del> <ins> if any.  Verify that the "certificate_request_context" begins with the supplied Request-ID, if any. </ins> Use the "validate" API to confirm the validity of the authenticator with regard to the generated request (if any).
Code change:
but I'd prefer a better recommendation here than "educate your customers."
Suppose a site is hosted on a particular provider (or CDN, equally). The customer flips the DNS entry to point to a new provider. However, the old provider doesn't know that and might continue to serve traffic via ORIGIN + Secondary Certificates for requests that originally reach the provider via other DNS records. It's current industry practice to leave the old provider configured and hot during a transition to ensure the graceful cutover. However, the DNS record change is considered to be sufficent. We might want to recommend that servers periodically ensure the DNS record points to them before serving Secondary Certificates / ORIGIN references. I think this is Security Considerations prose, not protocol elements or requirements, however.

Related discussion:
text: 6.4. <ins> CNAME records in the DNS are frequently used to delegate authority for an origin to a third-party provider.  This delegation can be changed without notice, even to the third-party provider, simply by modifying the CNAME record in question. After the owner of the domain has redirected traffic elsewhere by changing the CNAME, new connections will not arrive for that origin, but connections which are properly directed to this provider for other origins would continue to claim control of this origin (via ORIGIN frame and Secondary Certificates).  This is proper behavior based on the third-party provider's configuration, but would likely not be what is intended by the owner of the origin. This is not an issue which can be mitigated by the protocol, but something about which third-party providers SHOULD educate their customers before using the features described in this document. 6.5. </ins> Implementations need to be aware of the potential for confusion about the state of a connection.  The presence or absence of a validated certificate can change during the processing of a request,
Code change:
Serialisation of dictionary and param-list currently say instead of This fixes that.
Blah, good catch; thanks.

Related discussion:
text: For each member mem of input: <del> Let name be the result of applying Serialising an Identifier (ser-identifier) to mem's member-name. </del> <ins> Let name be the result of applying Serialising an Key (ser-key) to mem's member-name. </ins> Append name to output. Append "=" to output. <del> Let value be the result of applying Serialising a Key (ser-key) to mem's member-value. </del> <ins> Let value be the result of applying Serialising an Item (ser- item) to mem's member-value. </ins> Append value to output.
Code change:
Serialisation of dictionary and param-list currently say instead of This fixes that.
Blah, good catch; thanks.

Related discussion:
text: Append ";" to output. <del> Let name be the result of applying Serialising an Identifier (ser-identifier) to parameter's param-name. </del> <ins> Let name be the result of applying Serialising a Key (ser- key) to parameter's param-name. </ins> Append name to output. If parameter has a param-value: <del> Let value be the result of applying Serialising a Key (ser-key) to parameter's param-value. </del> <ins> Let value be the result of applying Serialising an Item (ser-item) to parameter's param-value. </ins> Append "=" to output.
Code change:
Suggested elaboration / re-focusing in the introduction to clarify how CH fits into things.
CI failed due to rfc-URL DNS failure; should be transient.
Feedback addressed, I think.
Thanks for working on this! A few comments...Looks great, thanks Mark! Based on recent direction and discussions, the sections that mention "defines initial set of hints" and reference to User-Agent header may need to be updated, but we'll tackle that in a separate thread.

Related discussion:
text: Abstract <del> An increasing diversity of Web-connected devices and software capabilities has created a need to deliver optimized content for each device. </del> <ins> HTTP defines proactive content negotiation to allow servers to select the appropriate response for a given request, based upon the user agent's characteristics, as expressed in request headers.  In practice, clients are often unwilling to send those request headers, because it is not clear whether they will be used, and sending them impacts both performance and privacy. </ins> <del> This specification defines an extensible and configurable set of HTTP request header fields, colloquially known as Client Hints, to address this.  They are intended to be used as input to proactive content negotiation; just as the Accept header field allows user agents to indicate what formats they prefer, Client Hints allow user agents to indicate device and agent specific preferences. </del> <ins> This specification defines a response header, Accept-CH, that servers can use to advertise their use of request headers for proactive content negotiation, along with a set of guidelines for the creation of such headers, colloquially known as "Client Hints." It also defines an initial set of Client Hints. </ins> Note to Readers
Code change:
Suggested elaboration / re-focusing in the introduction to clarify how CH fits into things.
CI failed due to rfc-URL DNS failure; should be transient.
Feedback addressed, I think.
Thanks for working on this! A few comments...Looks great, thanks Mark! Based on recent direction and discussions, the sections that mention "defines initial set of hints" and reference to User-Agent header may need to be updated, but we'll tackle that in a separate thread.

Related discussion:
text: A popular alternative strategy is to use HTTP cookies (RFC6265) to communicate some information about the user agent.  However, this approach is also not cache friendly, bound by same origin policy, and <del> imposes additional client-side latency by requiring JavaScript </del> <ins> often imposes additional client-side latency by requiring JavaScript </ins> execution to create and manage HTTP cookies. <del> This document defines a set of new request header fields that allow user agent to perform proactive content negotiation (Section 3.4.1 of RFC7231) by indicating device and agent specific preferences, through a mechanism similar to the Accept header field which is used to indicate preferred response formats. Client Hints does not supersede or replace the User-Agent header field.  Existing device detection mechanisms can continue to use both mechanisms if necessary.  By advertising its capabilities within a request header field, Client Hints allows for cache friendly and proactive content negotiation. </del> <ins> Proactive content negotiation (Section 3.4.1 of RFC7231) offers an alternative approach; user agents use specified, well-defined request headers to advertise their capabilities and characteristics, so that servers can select (or formulate) an appropriate response. However, proactive content negotiation requires clients to send these request headers prolifically.  This causes performance concerns (because it creates "bloat" in requests), as well as privacy issues (because these request headers can be used to "fingerprint" - i.e., uniquely identify - the user agent). This document defines a new response header, Accept-CH, that allows an origin server to explicitly ask that clients send these headers in requests, for a period of time bounded by the Accept-CH-Lifetime response header.  It also defines guidelines for content negotiation mechanisms that use it, colloquially referred to as Client Hints. Client Hints mitigate the performance concerns by assuring that clients will only send the request headers when they're actually going to be used, and the privacy concerns by creating positive evicence of their use (the use of the response header). This document also defines an initial set of Client Hints. It does not supersede or replace the User-Agent header field. Existing device detection mechanisms can continue to use both mechanisms if necessary.  By advertising user agent capabilities within a request header field, Client Hints allow for cache friendly and proactive content negotiation. </ins> 1.1.
Code change:
This change passes 'null' to the content-negotiation algorithm if the request header is absent. For list headers, the algorithms can always turn that into the empty list, but for non-list headers they need to come up with something appropriate to do. This also tries to do better about , but may not completely fix it.
Thanks.
URL says "... For each variant in variants-header ... Let request-value be the field-value(s) associated with field-name in incoming-request." I don't see any handling of the case where there is no header in . The algorithms in URL then also don't handle the case where request-value is empty. Sorry if I've just missed where you handle the empty case.

Related discussion:
text: field identified by a content negotiation mechanism that the implementation supports: <del> Let request-value be the field-value(s) associated with field-name in incoming-request. </del> <ins> Let request-value be the field-value associated with field-name in incoming-request (after being combined as allowed by Section 3.2.2 of RFC7230), or null if field- name is not in incoming-request. </ins> Let available-values be a list containing all available- value for variant.
Code change:
This change passes 'null' to the content-negotiation algorithm if the request header is absent. For list headers, the algorithms can always turn that into the empty list, but for non-list headers they need to come up with something appropriate to do. This also tries to do better about , but may not completely fix it.
Thanks.
URL says "... For each variant in variants-header ... Let request-value be the field-value(s) associated with field-name in incoming-request." I don't see any handling of the case where there is no header in . The algorithms in URL then also don't handle the case where request-value is empty. Sorry if I've just missed where you handle the empty case.

Related discussion:
text: MUST define an algorithm for selecting a result.  It MUST return a list of available-values that are suitable for the request, in order of preference, given the value of the request header <del> nominated above and an available-values list from the Variants header.  If the result is an empty list, it implies that the cache cannot satisfy the request. </del> <ins> nominated above (or null if the request header is absent) and an available-values list from the Variants header.  If the result is an empty list, it implies that the cache cannot satisfy the request. </ins> backports fulfils these requirements for some existing proactive content negotiation mechanisms in HTTP.