jiebi/CodeConvo huggingface dataset:
Code change:
Discussion at IETF 118 was that the didn't necessarily need to be short to reduce variations (was originally planning on 7 days) but chaning it to last-fetched instead of last-written is important. This updates the default to 14 days as a balance (can always be overridden explicitly).

Related discussion:
text: To be considered as a match, the dictionary must not yet be expired as a dictionary.  When iterating through dictionaries looking for a match, the expiration time of the dictionary is calculated by taking <del> the last time the dictionary was written and adding the "ttl" seconds </del> <ins> the last time the dictionary was fetched and adding the "ttl" seconds </ins> from the "Use-As-Dictionary" response.  If the current time is beyond the expiration time of the dictionary, it MUST be ignored.
Code change:
As brought up in , resumable uploads may interfere with intermediaries scanning the request content. This PR adds a paragraph in the security considerations. Closes URL
Some security measures that involve looking at incoming HTTP requests might be circumvented by resumable uploads. For example, a filter which looks for certain HTTP headers and corresponding text in the request payload might not be triggered when the header occurs in one request and the matching body fragment in a subsequent request. I don't believe there's anything we need to change about the protocol here, but it's probably mentioning this in Security Considerations. Perhaps guidance would be to ensure any security measures are either resumable-upload-aware or are explicitly called to inspect the final request between receipt of the last chunk and execution of the original request.
Thank you, that is a good point. I have opened to add a paragraph in this regard. Please let me know if that expresses the problem correctly.

Related discussion:
text: The upload resource URL is the identifier used for modifying the upload.  Without further protection of this URL, an attacker may obtain information about an upload, append data to it, or cancel it. To prevent this, the server SHOULD ensure that only authorized clients can access the upload resource.  In addition, the upload resource URL SHOULD be generated in such a way that makes it hard to be guessed by unauthorized clients. <ins> Some servers or intermediaries provide scanning of content uploaded by clients.  Any scanning mechanism that relies on receiving a complete file in a single request message can be defeated by resumable uploads because content can be split across multiple messages.  Servers or intermediaries wishing to perform content scanning SHOULD consider how resumable uploads can circumvent scanning and take appropriate measures.  Possible strategies include waiting for the upload to complete before scanning a full file, or disabling resumable uploads. </ins> 11. IANA is asked to register the following entries in the "Hypertext
Code change:
This adds support for a server-provided sf-string "id" of up to 1024 characters that is echoed back in a "Dictionary-ID" request header when the dictionary is advertised as being available. This allows for a server to use something other than the hash to retrieve the dictionary (i.e. a cache key). This should be more flexible than the client sending the original request URL and will allow for servers to store arbitrary context information with the dictionary. It doesn't open up any additional privacy or security concerns because the dictionary hash was already being treated as if it was user-identifiable information. For
NAME could you please take a look and see if this meets your needs and looks reasonable?
Yes, looks great! Thanks!

Related discussion:
text: The Use-As-Dictionary response header is a Structured Field STRUCTURED-FIELDS sf-dictionary with values for "match", "match- <del> search", "match-dest", "ttl", and "type". </del> <ins> search", "match-dest", "ttl", "id", and "type". </ins> 2.1.1.
Code change:
This adds support for a server-provided sf-string "id" of up to 1024 characters that is echoed back in a "Dictionary-ID" request header when the dictionary is advertised as being available. This allows for a server to use something other than the hash to retrieve the dictionary (i.e. a cache key). This should be more flexible than the client sending the original request URL and will allow for servers to store arbitrary context information with the dictionary. It doesn't open up any additional privacy or security concerns because the dictionary hash was already being treated as if it was user-identifiable information. For
NAME could you please take a look and see if this meets your needs and looks reasonable?
Yes, looks great! Thanks!

Related discussion:
text: 2.1.5. <ins> The "id" value of the Use-As-Dictionary header is a sf-string value that specifies a server identifier for the dictionary.  If an "id" value is present then it MUST be sent to the server in a "Dictionary- ID" request header when the dictionary is advertised as being available. The server identifier MUST be treated as an opaque string by the client. The server identifier MUST NOT be relied upon by the server to guarantee the contents of the dictionary.  The dictionary hash MUST be validated before use. The "id" value string length (after any decoding) supports up to 1024 characters. The "id" value is optional. 2.1.6. </ins> The "type" value of the Use-As-Dictionary header is a sf-string value that describes the file format of the supplied dictionary.
Code change:
This adds support for a server-provided sf-string "id" of up to 1024 characters that is echoed back in a "Dictionary-ID" request header when the dictionary is advertised as being available. This allows for a server to use something other than the hash to retrieve the dictionary (i.e. a cache key). This should be more flexible than the client sending the original request URL and will allow for servers to store arbitrary context information with the dictionary. It doesn't open up any additional privacy or security concerns because the dictionary hash was already being treated as if it was user-identifiable information. For
NAME could you please take a look and see if this meets your needs and looks reasonable?
Yes, looks great! Thanks!

Related discussion:
text: The "type" value is optional and defaults to "raw". <del> 2.1.6. </del> <ins> 2.1.7. </ins> <del> 2.1.6.1. </del> <ins> 2.1.7.1. </ins> A response that contained a response header:
Code change:
This adds support for a server-provided sf-string "id" of up to 1024 characters that is echoed back in a "Dictionary-ID" request header when the dictionary is advertised as being available. This allows for a server to use something other than the hash to retrieve the dictionary (i.e. a cache key). This should be more flexible than the client sending the original request URL and will allow for servers to store arbitrary context information with the dictionary. It doesn't open up any additional privacy or security concerns because the dictionary hash was already being treated as if it was user-identifiable information. For
NAME could you please take a look and see if this meets your needs and looks reasonable?
Yes, looks great! Thanks!

Related discussion:
text: expiring as a dictionary in 7 days independent of the cache lifetime of the resource. <del> 2.1.6.2. </del> <ins> 2.1.7.2. </ins> A response that contained a response header:
Code change:
This adds support for a server-provided sf-string "id" of up to 1024 characters that is echoed back in a "Dictionary-ID" request header when the dictionary is advertised as being available. This allows for a server to use something other than the hash to retrieve the dictionary (i.e. a cache key). This should be more flexible than the client sending the original request URL and will allow for servers to store arbitrary context information with the dictionary. It doesn't open up any additional privacy or security concerns because the dictionary hash was already being treated as if it was user-identifiable information. For
NAME could you please take a look and see if this meets your needs and looks reasonable?
Yes, looks great! Thanks!

Related discussion:
text: 2.3. <ins> When a HTTP client makes a request for a resource for which it has an appropriate dictionary and the dictionary was stored with a server- provided "id" in the Use-As-Dictionary response then the client MUST echo the stored "id" in a "Dictionary-ID" request header. The "Dictionary-ID" request header is a Structured Field STRUCTURED- FIELDS sf-string of up to 1024 characters (after any decoding) and MUST be identical to the server-provided "id". For example: 2.4. </ins> When a HTTP server responds with a resource that is encoded with a dictionary the server MUST send the hash of the dictionary that was used in the "Content-Dictionary" response header.
Code change:
This changes the URLPattern match to use a single match pattern to be consistent with other uses of URLPattern.
NAME NAME this is an attempt at a change to have it use a single string for pattern construction. I don't feel great about the same-origin check part of the validation but I don't see why it wouldn't work. It still allows for people to waste bytes by not using path-relative patterns so I may have to re-open the issue around that but should provide the consistency you were asking for. This would be instead of PR .
a couple nitpicks while passing by

Related discussion:
text: The Use-As-Dictionary response header is a Structured Field STRUCTURED-FIELDS sf-dictionary with values for "match", "match- <del> search", "match-dest", "ttl", "id", and "type". </del> <ins> dest", "ttl", "id", and "type". </ins> 2.1.1. The "match" value of the Use-As-Dictionary header is a sf-string <del> value that provides the "pathname" of a URLPattern (https://urlpattern.spec.whatwg.org/#dom-urlpatterninit-pathname). </del> <ins> value that provides the URLPattern to use for request matching (https://urlpattern.spec.whatwg.org/). </ins> <del> The "match" is a URL path relative to the full request URL of the dictionary.  The request URL for the dictionary itself is used as the "baseURL" for constructing the URLPattern (https://urlpattern.spec.whatwg.org/) that is used for matching the dictionary to relevant requests when running dictionary-url-matching. </del> <ins> The URLPattern used for matching does not support using Regular expressions. </ins> <del> The URLPattern used for request matching does not support regular expressions (https://urlpattern.spec.whatwg.org/#token-type-regexp) in the "match". </del> <ins> The following algorithm will return TRUE for a valid match pattern and FALSE for an invalid pattern that MUST NOT be used: </ins> <del> The "match" value is required and MUST be included in the Use-As- Dictionary sf-dictionary for the dictionary to be considered valid. </del> <ins> Let MATCH be the value of "match" for the given dictionary. </ins> <del> 2.1.2. </del> <ins> Let URL be the URL of the dictionary request. </ins> <del> The "match-search" value of the Use-As-Dictionary header is a sf- string value that provides the "search" of a URLPattern (https://urlpattern.spec.whatwg.org/#dom-urlpatterninit-search). </del> <ins> Let PATTERN be a URLPattern constructed by setting input=MATCH, and baseURL=URL (https://urlpattern.spec.whatwg.org/). </ins> <del> The "match-search" is the match pattern for the searchpart of the request URL and does not support regular expressions. </del> <ins> If PATTERN has regexp groups then return FALSE (https://urlpattern.spec.whatwg.org/#urlpattern-has-regexp- groups). </ins> <del> The "match-search" value is optional and defaults to the asterisk wildcard token "*". </del> <ins> Return True. </ins> <del> 2.1.3. </del> <ins> The "match" value is required and MUST be included in the Use-As- Dictionary sf-dictionary for the dictionary to be considered valid. 2.1.2. </ins> The "match-dest" value of the Use-As-Dictionary header is a sf-string value that provides a request destination
Code change:
This changes the URLPattern match to use a single match pattern to be consistent with other uses of URLPattern.
NAME NAME this is an attempt at a change to have it use a single string for pattern construction. I don't feel great about the same-origin check part of the validation but I don't see why it wouldn't work. It still allows for people to waste bytes by not using path-relative patterns so I may have to re-open the issue around that but should provide the consistency you were asking for. This would be instead of PR .
a couple nitpicks while passing by

Related discussion:
text: The "match-dest" value is optional and defaults to the empty string. <del> 2.1.4. </del> <ins> 2.1.3. </ins> The "ttl" value of the Use-As-Dictionary header is a sf-integer value that provides the time in seconds that the dictionary is valid for
Code change:
This changes the URLPattern match to use a single match pattern to be consistent with other uses of URLPattern.
NAME NAME this is an attempt at a change to have it use a single string for pattern construction. I don't feel great about the same-origin check part of the validation but I don't see why it wouldn't work. It still allows for people to waste bytes by not using path-relative patterns so I may have to re-open the issue around that but should provide the consistency you were asking for. This would be instead of PR .
a couple nitpicks while passing by

Related discussion:
text: The "ttl" value is optional and defaults to 1209600 (14 days). <del> 2.1.5. </del> <ins> 2.1.4. </ins> The "id" value of the Use-As-Dictionary header is a sf-string value that specifies a server identifier for the dictionary.  If an "id"
Code change:
This changes the URLPattern match to use a single match pattern to be consistent with other uses of URLPattern.
NAME NAME this is an attempt at a change to have it use a single string for pattern construction. I don't feel great about the same-origin check part of the validation but I don't see why it wouldn't work. It still allows for people to waste bytes by not using path-relative patterns so I may have to re-open the issue around that but should provide the consistency you were asking for. This would be instead of PR .
a couple nitpicks while passing by

Related discussion:
text: The "id" value is optional. <del> 2.1.6. </del> <ins> 2.1.5. </ins> The "type" value of the Use-As-Dictionary header is a sf-string value that describes the file format of the supplied dictionary.
Code change:
This changes the URLPattern match to use a single match pattern to be consistent with other uses of URLPattern.
NAME NAME this is an attempt at a change to have it use a single string for pattern construction. I don't feel great about the same-origin check part of the validation but I don't see why it wouldn't work. It still allows for people to waste bytes by not using path-relative patterns so I may have to re-open the issue around that but should provide the consistency you were asking for. This would be instead of PR .
a couple nitpicks while passing by

Related discussion:
text: The "type" value is optional and defaults to "raw". <del> 2.1.7. </del> <ins> 2.1.6. </ins> <del> 2.1.7.1. </del> <ins> 2.1.6.1. </ins> A response that contained a response header:
Code change:
This changes the URLPattern match to use a single match pattern to be consistent with other uses of URLPattern.
NAME NAME this is an attempt at a change to have it use a single string for pattern construction. I don't feel great about the same-origin check part of the validation but I don't see why it wouldn't work. It still allows for people to waste bytes by not using path-relative patterns so I may have to re-open the issue around that but should provide the consistency you were asking for. This would be instead of PR .
a couple nitpicks while passing by

Related discussion:
text: expiring as a dictionary in 7 days independent of the cache lifetime of the resource. <del> 2.1.7.2. </del> <ins> 2.1.6.2. </ins> A response that contained a response header:
Code change:
This changes the URLPattern match to use a single match pattern to be consistent with other uses of URLPattern.
NAME NAME this is an attempt at a change to have it use a single string for pattern construction. I don't feel great about the same-origin check part of the validation but I don't see why it wouldn't work. It still allows for people to waste bytes by not using path-relative patterns so I may have to re-open the issue around that but should provide the consistency you were asking for. This would be instead of PR .
a couple nitpicks while passing by

Related discussion:
text: 2.2.2. When a dictionary is stored as a result of a "Use-As-Dictionary" <del> directive, it includes "match", "match-search" and "match-dest" strings that are used to match an outgoing request from a client to the available dictionaries. </del> <ins> directive, it includes "match" and "match-dest" strings that are used to match an outgoing request from a client to the available dictionaries. Dictionaries MUST have been served from the same {Origin} as the outgoing request to match. </ins> To see if an outbound request matches a given dictionary, the following algorithm will return TRUE for a successful match and FALSE
Code change:
This changes the URLPattern match to use a single match pattern to be consistent with other uses of URLPattern.
NAME NAME this is an attempt at a change to have it use a single string for pattern construction. I don't feel great about the same-origin check part of the validation but I don't see why it wouldn't work. It still allows for people to waste bytes by not using path-relative patterns so I may have to re-open the issue around that but should provide the consistency you were asking for. This would be instead of PR .
a couple nitpicks while passing by

Related discussion:
text: If DEST is not an empty string and If DEST and REQUEST_DEST are not the same value, return FALSE <del> Let PATH be the value of "match" for the given dictionary. </del> <ins> Let BASEURL be the URL of the dictionary request. </ins> <del> Let SEARCH be the value of "match-search" for the given dictionary. </del> <ins> Let URL represent the URL of the outbound request being checked. </ins> <del> Let BASEURL be the request URL of the given dictionary. </del> <ins> If the {Origin} of BASEURL and the {Origin} of URL are not the same, return FALSE. </ins> <del> Let PATTERN be a URLPattern constructed by setting pathname=PATH, search=SEARCH, baseURL=BASEURL (https://urlpattern.spec.whatwg.org/). </del> <ins> Let MATCH be the value of "match" for the given dictionary. </ins> <del> LET URL represent the request URL being checked. </del> <ins> Let PATTERN be a URLPattern constructed by setting input=MATCH, and baseURL=BASEURL (https://urlpattern.spec.whatwg.org/). </ins> <del> Return the result of running the URLPattern "match" algorithm (https://urlpattern.spec.whatwg.org/#match) </del> <ins> Return the result of running the "test" method of PATTERN with input=URL (https://urlpattern.spec.whatwg.org/#ref-for-dom- urlpattern-test) </ins> 2.2.3.
Code change:
This changes the URLPattern match to use a single match pattern to be consistent with other uses of URLPattern.
NAME NAME this is an attempt at a change to have it use a single string for pattern construction. I don't feel great about the same-origin check part of the validation but I don't see why it wouldn't work. It still allows for people to waste bytes by not using path-relative patterns so I may have to re-open the issue around that but should provide the consistency you were asking for. This would be instead of PR .
a couple nitpicks while passing by

Related discussion:
text: specifies and matches a "match-dest" takes precedence over a match that does not use a destination.  1.  Given equivalent destination precedence, the dictionary with the longest "match" takes precedence. <del> 1.  Given equivalent destination and path precedence, the dictionary with the longest "match-search" takes precedence.  1.  Given equivalent destination, path and search precedence, the most recently fetched dictionary takes precedence. </del> <ins> 1.  Given equivalent destination and match length precedence, the most recently fetched dictionary takes precedence. </ins> 2.3.
Code change:
After looking harder, I found that RFC 9110 that a proxy "is usually identified by an "http" or "https" URI". I'm not sure that's 100% accurate, but it conveniently resolves the wording problem, and who am I to argue with RFC 9110?
At the moment, section 1.2 (Problems) start with the following sentence: I totally get what it tries to say, but it is confusing if not incorrect. states that a CONNECT request is handled by a "proxy" and the target specified by the "host:port" tuple is the "origin." Therefore, HTTP CONNECT proxies are not identified by an origin. Rather, they are identified by the user's proxy settings. I think we'd better update the problem statement, and might also consider pointing out that the definition of "origin" will be different between CONNECT and connect-tcp (or use different terms to identify the CONNECT target and the entity that creates a tunnel in order to avoid confusion, maybe?).
PS. Practical example showcasing the side effect of the change to the definition is that the way to authenticate becomes different; when a client tries to establish a CONNECT tunnel with authentication, it uses "proxy-authorization" header, whereas when a client tries to establish a connect-tcp tunnel, it uses "authorization." I think it's worth noting.
I'm realizing that this spec has the opportunity to fix the origin issues present in regular CONNECT. While we're there it'd be great to clarify how connect-tcp interacts with Alt-Svc because it's unclear for CONNECT. I sent some more about why it's unclear for CONNECT.
Thanks for the discussion!

Related discussion:
text: usual requirements for classic CONNECT proxies in this HTTP version (see RFC9113 and RFC9114). <ins> 3.3. A templated TCP proxy has an unambiguous origin of its own.  Origin- scoped HTTP header fields such as "Alt-Svc" RFC7838 and "Strict- Transport-Security" RFC6797 apply to this origin when they are associated with a templated TCP proxy request or response. </ins> 4. This section discusses some behaviors that are permitted or
Code change:
This is kinda silly, but it seems like adding support for coalescing is something we could fix later. with the nuclear option.
the pull request is fine by me. I do wonder if we shouldn't make the json a tad more complicated to allow for a reasonable mixed definition in the future. But an unreasonable one is obviously possible :)
Can we coalesce http and https? The implication from everything we've said is "yes", but Erik remains reluctant.

Related discussion:
text: 2.2. Clients MUST NOT send "http" requests and "https" requests on the <del> same connection. </del> <ins> same connection.  Similarly, clients MUST NOT send "http" requests for multiple origins on the same connection. </ins> 2.3.