jiebi/CodeConvo huggingface dataset:
Code change:
Please correct me if I'm wrong, but IIUC, the crux of this PR is that to allow any client that can present a valid pair of Authorization and Signature-Auth-Context header fields to obtain a protected resource. Assuming that if we would be allowing such behavior, I wonder why we need to require clients to export keys from TLS session, rather than just coming up with some arbitrary authentication context and present it to the server? Or if it is the case that there are situations in which we have to require clients to use keys exported from TLS session, doesn't it mean that there are cases where servers must ignore Signature-Authentication-Context header field or drop it?
NAME no this is only for trusted intermediaries. If a server receives a Signature-Auth-Context header from an untrusted source then it drops it. That's somewhat mentioned on line 470, but I'll add normative text.

Related discussion:
text: (see output}), and forward it to the upstream HTTP server, then the upstream server performs the validation. <del> The mechanism for the intermediary to communicate this information to the upstream HTTP server is out of scope for this document. </del> <ins> This document defines the "Signature-Auth-Context" request header field for this latter purpose.  The Signature-Auth-Context header field's value is a Structured Field Byte Sequence (see STRUCTURED- FIELDS) that contains the 48-byte key exporter output (see output), without any parameters.  For example: </ins> Note that both of these mechanisms require the upstream HTTP server to trust the intermediary.  This is usually the case because the intermediary already needs access to the TLS certificate private key <del> in order to respond to requests. </del> <ins> in order to respond to requests.  HTTP servers that parse the Signature-Auth-Context header field MUST ignore it unless they have already established that they trust the sender. </ins> 9.
Code change:
Please correct me if I'm wrong, but IIUC, the crux of this PR is that to allow any client that can present a valid pair of Authorization and Signature-Auth-Context header fields to obtain a protected resource. Assuming that if we would be allowing such behavior, I wonder why we need to require clients to export keys from TLS session, rather than just coming up with some arbitrary authentication context and present it to the server? Or if it is the case that there are situations in which we have to require clients to use keys exported from TLS session, doesn't it mean that there are cases where servers must ignore Signature-Authentication-Context header field or drop it?
NAME no this is only for trusted intermediaries. If a server receives a Signature-Auth-Context header from an untrusted source then it drops it. That's somewhat mentioned on line 470, but I'll add normative text.

Related discussion:
text: This document, if approved, requests IANA to register the following entry in the "TLS Exporter Labels" registry maintained at <<https://www.iana.org/assignments/tls-parameters#exporter-labels>>: <ins> 10.3. This document, if approved, requests IANA to register the following entry in the "Hypertext Transfer Protocol (HTTP) Field Name" registry maintained at <<https://www.iana.org/assignments/http-fields/http- fields.xhtml>>: </ins>
Code change:
Changed it to a proper normative reference. For
Merging this. Can always clean it up more if it is still a concern.
For example: Usually, we add something like URLPattern to the references, then that.
Sorry, didn't mean to close the issue. Feel free to close this out if the current language looks OK (also happy to update it if it needs some more tweaking).
Going to close this out now. Thanks for taking the time on this.

Related discussion:
text: 2.1.1. The "match" value of the Use-As-Dictionary header is a String value <del> that provides the URLPattern to use for request matching (https://urlpattern.spec.whatwg.org/). </del> <ins> that provides the URL Pattern URLPattern to use for request matching. </ins> <del> The URLPattern used for matching does not support using Regular </del> <ins> The URL Pattern used for matching does not support using Regular </ins> expressions. The following algorithm will return TRUE for a valid match pattern
Code change:
Changed it to a proper normative reference. For
Merging this. Can always clean it up more if it is still a concern.
For example: Usually, we add something like URLPattern to the references, then that.
Sorry, didn't mean to close the issue. Feel free to close this out if the current language looks OK (also happy to update it if it needs some more tweaking).
Going to close this out now. Thanks for taking the time on this.

Related discussion:
text: Let URL be the URL of the dictionary request. <del> Let PATTERN be a URLPattern constructed by setting input=MATCH, and baseURL=URL (https://urlpattern.spec.whatwg.org/). </del> <ins> Let PATTERN be a URL Pattern URLPattern constructed by setting input=MATCH, and baseURL=URL. </ins> <del> If PATTERN has regexp groups then return FALSE (https://urlpattern.spec.whatwg.org/#urlpattern-has-regexp- groups). </del> <ins> If PATTERN has regexp groups then return FALSE. </ins> Return True.
Code change:
Changed it to a proper normative reference. For
Merging this. Can always clean it up more if it is still a concern.
For example: Usually, we add something like URLPattern to the references, then that.
Sorry, didn't mean to close the issue. Feel free to close this out if the current language looks OK (also happy to update it if it needs some more tweaking).
Going to close this out now. Thanks for taking the time on this.

Related discussion:
text: Let MATCH be the value of "match" for the given dictionary. <del> Let PATTERN be a URLPattern constructed by setting input=MATCH, and baseURL=BASEURL (https://urlpattern.spec.whatwg.org/). </del> <ins> Let PATTERN be a URL Pattern URLPattern constructed by setting input=MATCH, and baseURL=BASEURL. </ins> Return the result of running the "test" method of PATTERN with <del> input=URL (https://urlpattern.spec.whatwg.org/#ref-for-dom- urlpattern-test) </del> <ins> input=URL. </ins> 2.2.3.
Code change:
Changed it to a proper normative reference. For
Merging this. Can always clean it up more if it is still a concern.
For example: Usually, we add something like URLPattern to the references, then that.
Sorry, didn't mean to close the issue. Feel free to close this out if the current language looks OK (also happy to update it if it needs some more tweaking).
Going to close this out now. Thanks for taking the time on this.

Related discussion:
text: 6.3.1. To make sure that a dictionary can only impact content from the same <del> origin where the dictionary was served, the URLPattern used for matching a dictionary to requests is guaranteed to be for the same origin that the dictionary is served from. </del> <ins> origin where the dictionary was served, the URL Pattern used for matching a dictionary to requests (match) is guaranteed to be for the same origin that the dictionary is served from. </ins> 6.3.2.
Code change:
The CONNECT-TCP draft makes informative references to other drafts which use "extended CONNECT" (CONNECT-UDP, CONNECT-IP), but does not have a normative reference to the draft which defines this use of the CONNECT method. It references the "extended CONNECT" method without supplying a reference for this term. This draft spells out the required values for each pseudo-header, but omits the requirement to set SETTINGSENABLECONNECT_PROTOCOL. A reference to RFCs 8441/9220 is probably needed, and a reminder that the method in this document can only be used if the server sends this setting first.
That'll do.

Related discussion:
text: 3.2. <del> In HTTP/2 and HTTP/3, the client uses the proxy by issuing an "extended CONNECT" request as follows: </del> <ins> In HTTP/2 and HTTP/3, the proxy MUST include SETTINGS_ENABLE_CONNECT_PROTOCOL in its SETTINGS frame RFC9220.  The client uses the proxy by issuing an "extended CONNECT" request as follows: </ins> The :method pseudo-header field SHALL be "CONNECT".
Code change:
Adds language to the to not send the dictionary-aware encodings when a dictionary is not available (or when one is available but not being used). The dictionary-based encodings don't work without a dictionary (they contain a header that has the dictionary hash) and should not be advertised when they are not really available.
Thanks

Related discussion:
text: 6.1. <del> The client adds the content encodings that it supports to the "Accept-Encoding" request header. e.g.: </del> <ins> When a dictionary is available for use on a given request, and the client chooses to make dictionary-based content-encoding available, the client adds the dictionary-aware content encodings that it supports to the "Accept-Encoding" request header. e.g.: When a client does not have a stored dictionary that matches the request, or chooses not to use one for the request, the client MUST NOT send its dictionary-aware content-encodings in the "Accept- Encoding" request header. </ins> 6.2.
Code change:
Updates some out of date portions of the IANA considerations section. See for more info
NAME Ping
NAME Ping
Some aspects of the IANA considerations section are outdated and should be updated: The “Cookie” and “Set-Cookie” registrations from RFC 6265 have been moved from the “Permanent Message Header Field Names” registry to the “HTTP Field Name Registry” Update Sections 9.1 (Cookie) and 9.2 (Set-Cookie)The word "Registry" should be omitted from registry names. Update Section 9.3 (Cookie Attribute Registry)
LGTM. Apologies I missed this.

Related discussion:
text: USASCII character), and WSP (whitespace). The OWS (optional whitespace) and BWS (bad whitespace) rules are <del> defined in Section 5.6.3 of HTTPSEM. </del> <ins> defined in Section 5.6.3 of RFC9110. </ins> 2.3. The terms "user agent", "client", "server", "proxy", and "origin server" have the same meaning as in the HTTP/1.1 specification <del> (HTTPSEM, Section 3). </del> <ins> (RFC9110, Section 3). </ins> The request-host is the name of the host, as known by the user agent, to which the user agent is sending an HTTP request or from which it
Code change:
Updates some out of date portions of the IANA considerations section. See for more info
NAME Ping
NAME Ping
Some aspects of the IANA considerations section are outdated and should be updated: The “Cookie” and “Set-Cookie” registrations from RFC 6265 have been moved from the “Permanent Message Header Field Names” registry to the “HTTP Field Name Registry” Update Sections 9.1 (Cookie) and 9.2 (Set-Cookie)The word "Registry" should be omitted from registry names. Update Section 9.3 (Cookie Attribute Registry)
LGTM. Apologies I missed this.

Related discussion:
text: sent the corresponding HTTP request). The term request-uri refers to "target URI" as defined in Section 7.1 <del> of HTTPSEM. </del> <ins> of RFC9110. </ins> Two sequences of octets are said to case-insensitively match each other if and only if they are equivalent under the i;ascii-casemap
Code change:
Updates some out of date portions of the IANA considerations section. See for more info
NAME Ping
NAME Ping
Some aspects of the IANA considerations section are outdated and should be updated: The “Cookie” and “Set-Cookie” registrations from RFC 6265 have been moved from the “Permanent Message Header Field Names” registry to the “HTTP Field Name Registry” Update Sections 9.1 (Cookie) and 9.2 (Set-Cookie)The word "Registry" should be omitted from registry names. Update Section 9.3 (Cookie Attribute Registry)
LGTM. Apologies I missed this.

Related discussion:
text: RFC6454. "Safe" HTTP methods include "GET", "HEAD", "OPTIONS", and "TRACE", as <del> defined in Section 9.2.1 of HTTPSEM. </del> <ins> defined in Section 9.2.1 of RFC9110. </ins> A domain's "public suffix" is the portion of a domain that is controlled by a public registry, such as "com", "co.uk", and
Code change:
Updates some out of date portions of the IANA considerations section. See for more info
NAME Ping
NAME Ping
Some aspects of the IANA considerations section are outdated and should be updated: The “Cookie” and “Set-Cookie” registrations from RFC 6265 have been moved from the “Permanent Message Header Field Names” registry to the “HTTP Field Name Registry” Update Sections 9.1 (Cookie) and 9.2 (Set-Cookie)The word "Registry" should be omitted from registry names. Update Section 9.3 (Cookie Attribute Registry)
LGTM. Apologies I missed this.

Related discussion:
text: Origin servers SHOULD NOT fold multiple Set-Cookie header fields into a single header field.  The usual mechanism for folding HTTP headers <del> fields (i.e., as defined in Section 5.3 of HTTPSEM) might change the </del> <ins> fields (i.e., as defined in Section 5.3 of RFC9110) might change the </ins> semantics of the Set-Cookie header field because the %x2C (",") character is used by Set-Cookie in a way that conflicts with such folding.
Code change:
Updates some out of date portions of the IANA considerations section. See for more info
NAME Ping
NAME Ping
Some aspects of the IANA considerations section are outdated and should be updated: The “Cookie” and “Set-Cookie” registrations from RFC 6265 have been moved from the “Permanent Message Header Field Names” registry to the “HTTP Field Name Registry” Update Sections 9.1 (Cookie) and 9.2 (Set-Cookie)The word "Registry" should be omitted from registry names. Update Section 9.3 (Cookie Attribute Registry)
LGTM. Apologies I missed this.

Related discussion:
text: risk of CSRF attacks, developers may set the "SameSite" attribute in a "Lax" enforcement mode that carves out an exception which sends same-site cookies along with cross-site requests if and only if they <del> are top-level navigations which use a "safe" (in the HTTPSEM sense) </del> <ins> are top-level navigations which use a "safe" (in the RFC9110 sense) </ins> HTTP method.  (Note that a request's method may be changed from POST to GET for some redirects (see Sections 15.4.2 and 15.4.3 of <del> HTTPSEM); in these cases, a request's "safe"ness is determined based </del> <ins> RFC9110); in these cases, a request's "safe"ness is determined based </ins> on the method of the current redirect hop.) Lax enforcement provides reasonable defense in depth against CSRF
Code change:
Updates some out of date portions of the IANA considerations section. See for more info
NAME Ping
NAME Ping
Some aspects of the IANA considerations section are outdated and should be updated: The “Cookie” and “Set-Cookie” registrations from RFC 6265 have been moved from the “Permanent Message Header Field Names” registry to the “HTTP Field Name Registry” Update Sections 9.1 (Cookie) and 9.2 (Set-Cookie)The word "Registry" should be omitted from registry names. Update Section 9.3 (Cookie Attribute Registry)
LGTM. Apologies I missed this.

Related discussion:
text: 9.1. <del> The permanent message header field registry (see RFC3864) needs to be </del> <ins> The HTTP Field Name Registry (see HttpFieldNameRegistry) needs to be </ins> updated with the following registration: Cookie
Code change:
Updates some out of date portions of the IANA considerations section. See for more info
NAME Ping
NAME Ping
Some aspects of the IANA considerations section are outdated and should be updated: The “Cookie” and “Set-Cookie” registrations from RFC 6265 have been moved from the “Permanent Message Header Field Names” registry to the “HTTP Field Name Registry” Update Sections 9.1 (Cookie) and 9.2 (Set-Cookie)The word "Registry" should be omitted from registry names. Update Section 9.3 (Cookie Attribute Registry)
LGTM. Apologies I missed this.

Related discussion:
text: 9.2. <del> The permanent message header field registry (see RFC3864) needs to be updated with the following registration: </del> <ins> The permanent message header field registry (see HttpFieldNameRegistry) needs to be updated with the following registration: </ins> Set-Cookie
Code change:
Updates some out of date portions of the IANA considerations section. See for more info
NAME Ping
NAME Ping
Some aspects of the IANA considerations section are outdated and should be updated: The “Cookie” and “Set-Cookie” registrations from RFC 6265 have been moved from the “Permanent Message Header Field Names” registry to the “HTTP Field Name Registry” Update Sections 9.1 (Cookie) and 9.2 (Set-Cookie)The word "Registry" should be omitted from registry names. Update Section 9.3 (Cookie Attribute Registry)
LGTM. Apologies I missed this.

Related discussion:
text: 9.3. <del> IANA is requested to create the "Cookie Attribute Registry", defining </del> <ins> IANA is requested to create the "Cookie Attribute" registry, defining </ins> the name space of attribute used to control cookies' behavior.  The registry should be maintained at https://www.iana.org/assignments/ cookie-attribute-names [1].
Code change:
HTTPSEM has been published as RFC9110, update all reference to reflect this.
NAME Can you PTAL? I spot checked that existing section #s still matched up, but I would appreciate another look.
The sections should be stable, see . I'd also change "HTTPSEM" to just "HTTP2".
Sorry, not sure I understand.
Oops. I meant to say: I'd also change "HTTPSEM" to just "HTTP". See URL
Thanks, the latest commit should fix that.
Still LGTM. Thanks!

Related discussion:
text: USASCII character), and WSP (whitespace). The OWS (optional whitespace) and BWS (bad whitespace) rules are <del> defined in Section 5.6.3 of HTTPSEM. </del> <ins> defined in Section 5.6.3 of RFC9110. </ins> 2.3. The terms "user agent", "client", "server", "proxy", and "origin server" have the same meaning as in the HTTP/1.1 specification <del> (HTTPSEM, Section 3). </del> <ins> (RFC9110, Section 3). </ins> The request-host is the name of the host, as known by the user agent, to which the user agent is sending an HTTP request or from which it
Code change:
HTTPSEM has been published as RFC9110, update all reference to reflect this.
NAME Can you PTAL? I spot checked that existing section #s still matched up, but I would appreciate another look.
The sections should be stable, see . I'd also change "HTTPSEM" to just "HTTP2".
Sorry, not sure I understand.
Oops. I meant to say: I'd also change "HTTPSEM" to just "HTTP". See URL
Thanks, the latest commit should fix that.
Still LGTM. Thanks!

Related discussion:
text: sent the corresponding HTTP request). The term request-uri refers to "target URI" as defined in Section 7.1 <del> of HTTPSEM. </del> <ins> of RFC9110. </ins> Two sequences of octets are said to case-insensitively match each other if and only if they are equivalent under the i;ascii-casemap
Code change:
HTTPSEM has been published as RFC9110, update all reference to reflect this.
NAME Can you PTAL? I spot checked that existing section #s still matched up, but I would appreciate another look.
The sections should be stable, see . I'd also change "HTTPSEM" to just "HTTP2".
Sorry, not sure I understand.
Oops. I meant to say: I'd also change "HTTPSEM" to just "HTTP". See URL
Thanks, the latest commit should fix that.
Still LGTM. Thanks!

Related discussion:
text: RFC6454. "Safe" HTTP methods include "GET", "HEAD", "OPTIONS", and "TRACE", as <del> defined in Section 9.2.1 of HTTPSEM. </del> <ins> defined in Section 9.2.1 of RFC9110. </ins> A domain's "public suffix" is the portion of a domain that is controlled by a public registry, such as "com", "co.uk", and
Code change:
HTTPSEM has been published as RFC9110, update all reference to reflect this.
NAME Can you PTAL? I spot checked that existing section #s still matched up, but I would appreciate another look.
The sections should be stable, see . I'd also change "HTTPSEM" to just "HTTP2".
Sorry, not sure I understand.
Oops. I meant to say: I'd also change "HTTPSEM" to just "HTTP". See URL
Thanks, the latest commit should fix that.
Still LGTM. Thanks!

Related discussion:
text: Origin servers SHOULD NOT fold multiple Set-Cookie header fields into a single header field.  The usual mechanism for folding HTTP headers <del> fields (i.e., as defined in Section 5.3 of HTTPSEM) might change the </del> <ins> fields (i.e., as defined in Section 5.3 of RFC9110) might change the </ins> semantics of the Set-Cookie header field because the %x2C (",") character is used by Set-Cookie in a way that conflicts with such folding.
Code change:
HTTPSEM has been published as RFC9110, update all reference to reflect this.
NAME Can you PTAL? I spot checked that existing section #s still matched up, but I would appreciate another look.
The sections should be stable, see . I'd also change "HTTPSEM" to just "HTTP2".
Sorry, not sure I understand.
Oops. I meant to say: I'd also change "HTTPSEM" to just "HTTP". See URL
Thanks, the latest commit should fix that.
Still LGTM. Thanks!

Related discussion:
text: risk of CSRF attacks, developers may set the "SameSite" attribute in a "Lax" enforcement mode that carves out an exception which sends same-site cookies along with cross-site requests if and only if they <del> are top-level navigations which use a "safe" (in the HTTPSEM sense) </del> <ins> are top-level navigations which use a "safe" (in the RFC9110 sense) </ins> HTTP method.  (Note that a request's method may be changed from POST to GET for some redirects (see Sections 15.4.2 and 15.4.3 of <del> HTTPSEM); in these cases, a request's "safe"ness is determined based </del> <ins> RFC9110); in these cases, a request's "safe"ness is determined based </ins> on the method of the current redirect hop.) Lax enforcement provides reasonable defense in depth against CSRF
Code change:
In 4.2, the parameter is "a byte sequence that contains the public key", and the encoding of the public key is taken from Section 3.1. When reading this, I was initially unclear whether was only the key or the entire structure defined in Section 3.1 or another structure, particularly given the use of the word "contains." I might clarify that the parameter is the public key, and perhaps point from both 3.1 and 4.2 to the same place for how to get the bytes which are being base64url-encoded here. (Make a 3.1.1?) (Marking editorial, as I don't think I'm asking for a technical change here, just clarification of how this already works.)
What you're describing is indeed what we intended. I'm write up an editorial PR to clarify this.

Related discussion:
text: encoding from QUIC and MUST be encoded in the minimum number of bytes necessary. <del> The encoding of the public key is determined by the Signature </del> <ins> 3.1.1. Both the "Public Key" field of the TLS key exporter context (see above) and the "a" Parameter (see parameter-a) carry the same public key.  The encoding of the public key is determined by the Signature </ins> Algorithm in use as follows: This document does not define the public key encodings for other
Code change:
In 4.2, the parameter is "a byte sequence that contains the public key", and the encoding of the public key is taken from Section 3.1. When reading this, I was initially unclear whether was only the key or the entire structure defined in Section 3.1 or another structure, particularly given the use of the word "contains." I might clarify that the parameter is the public key, and perhaps point from both 3.1 and 4.2 to the same place for how to get the bytes which are being base64url-encoded here. (Make a 3.1.1?) (Marking editorial, as I don't think I'm asking for a technical change here, just clarification of how this already works.)
What you're describing is indeed what we intended. I'm write up an editorial PR to clarify this.

Related discussion:
text: 4.2. The REQUIRED "a" (public key) parameter is a byte sequence that <del> contains the public key used by the server to validate the signature </del> <ins> specifies the public key used by the server to validate the signature </ins> provided by the client.  This avoids key confusion issues (see SEEMS- <del> LEGIT).  The encoding of the public key is described in context. </del> <ins> LEGIT).  The encoding of the public key is described in public-key- encoding. </ins> 4.3.