jiebi/CodeConvo huggingface dataset:
Code change:
... and allow token to start with "*".
I'm running my SH implementation against the HTTP Archive dumps (400,000,000+ HTTP requests) to see how the from BSH parse in something like the real world. It looks like some headers are failing because AcceptAccess-Control-Allow-Origin`. If we were to use a different character to delimit Byte Sequences, we could include in Token (necessarily as a first character, as well as in the rest, I assume). Worthwhile? If so, what should we use for Byte Sequences?
(via ) already allows , but not as a first character. '%' is short in HPACK and unlikely to trigger funny handling, but maybe it will conflict with pct-encoding to start. '=' has the virtue of being already allowed. It has the drawback of causing byte array parameters to look funny ( for instance). Interestingly, it makes removal of padding easier (base64 padding is silly).
How about ? I don't' think is a good idea; if an implementation enforces padding (which we caution against, but do not prohibit), it's confusing.
Checking with NAME NAME - any issues changing byte sequence delimiters from to ?
(the only conflicting use that comes to mind ATM for is that if someone wants to refer to H2 pseudo-headers like in a field that uses tokens, they'll be out of luck. I think that's OK, because existing fields that take header names as a list-of-tokens don't refer to pseudo-headers, and new fields can be defined as lists of tokens-or-strings.)
is free

Related discussion:
text: Given a token as input_token, return an ASCII string suitable for use in a HTTP header value. <del> If input_token is not a sequence of characters, or contains a </del> <ins> If input_token is not a sequence of characters, the first character is not ALPHA or "*", or the remaining contain a </ins> character not in tchar, ":" or "/", fail serialisation. Let output be an empty string.
Code change:
... and allow token to start with "*".
I'm running my SH implementation against the HTTP Archive dumps (400,000,000+ HTTP requests) to see how the from BSH parse in something like the real world. It looks like some headers are failing because AcceptAccess-Control-Allow-Origin`. If we were to use a different character to delimit Byte Sequences, we could include in Token (necessarily as a first character, as well as in the rest, I assume). Worthwhile? If so, what should we use for Byte Sequences?
(via ) already allows , but not as a first character. '%' is short in HPACK and unlikely to trigger funny handling, but maybe it will conflict with pct-encoding to start. '=' has the virtue of being already allowed. It has the drawback of causing byte array parameters to look funny ( for instance). Interestingly, it makes removal of padding easier (base64 padding is silly).
How about ? I don't' think is a good idea; if an implementation enforces padding (which we caution against, but do not prohibit), it's confusing.
Checking with NAME NAME - any issues changing byte sequence delimiters from to ?
(the only conflicting use that comes to mind ATM for is that if someone wants to refer to H2 pseudo-headers like in a field that uses tokens, they'll be out of luck. I think that's OK, because existing fields that take header names as a list-of-tokens don't refer to pseudo-headers, and new fields can be defined as lists of tokens-or-strings.)
is free

Related discussion:
text: Let output be an empty string. <del> Append "*" to output. </del> <ins> Append ":" to output. </ins> Append the result of base64-encoding input_bytes as per RFC4648, Section 4, taking account of the requirements below. <del> Append "*" to output. </del> <ins> Append ":" to output. </ins> Return output.
Code change:
... and allow token to start with "*".
I'm running my SH implementation against the HTTP Archive dumps (400,000,000+ HTTP requests) to see how the from BSH parse in something like the real world. It looks like some headers are failing because AcceptAccess-Control-Allow-Origin`. If we were to use a different character to delimit Byte Sequences, we could include in Token (necessarily as a first character, as well as in the rest, I assume). Worthwhile? If so, what should we use for Byte Sequences?
(via ) already allows , but not as a first character. '%' is short in HPACK and unlikely to trigger funny handling, but maybe it will conflict with pct-encoding to start. '=' has the virtue of being already allowed. It has the drawback of causing byte array parameters to look funny ( for instance). Interestingly, it makes removal of padding easier (base64 padding is silly).
How about ? I don't' think is a good idea; if an implementation enforces padding (which we caution against, but do not prohibit), it's confusing.
Checking with NAME NAME - any issues changing byte sequence delimiters from to ?
(the only conflicting use that comes to mind ATM for is that if someone wants to refer to H2 pseudo-headers like in a field that uses tokens, they'll be out of luck. I think that's OK, because existing fields that take header names as a list-of-tokens don't refer to pseudo-headers, and new fields can be defined as lists of tokens-or-strings.)
is free

Related discussion:
text: Given an ASCII string as input_string, return a token. input_string is modified to remove the parsed value. <del> If the first character of input_string is not ALPHA, fail parsing. </del> <ins> If the first character of input_string is not ALPHA or "*", fail parsing. </ins> Let output_string be an empty string.
Code change:
... and allow token to start with "*".
I'm running my SH implementation against the HTTP Archive dumps (400,000,000+ HTTP requests) to see how the from BSH parse in something like the real world. It looks like some headers are failing because AcceptAccess-Control-Allow-Origin`. If we were to use a different character to delimit Byte Sequences, we could include in Token (necessarily as a first character, as well as in the rest, I assume). Worthwhile? If so, what should we use for Byte Sequences?
(via ) already allows , but not as a first character. '%' is short in HPACK and unlikely to trigger funny handling, but maybe it will conflict with pct-encoding to start. '=' has the virtue of being already allowed. It has the drawback of causing byte array parameters to look funny ( for instance). Interestingly, it makes removal of padding easier (base64 padding is silly).
How about ? I don't' think is a good idea; if an implementation enforces padding (which we caution against, but do not prohibit), it's confusing.
Checking with NAME NAME - any issues changing byte sequence delimiters from to ?
(the only conflicting use that comes to mind ATM for is that if someone wants to refer to H2 pseudo-headers like in a field that uses tokens, they'll be out of luck. I think that's OK, because existing fields that take header names as a list-of-tokens don't refer to pseudo-headers, and new fields can be defined as lists of tokens-or-strings.)
is free

Related discussion:
text: Given an ASCII string as input_string, return a byte sequence. input_string is modified to remove the parsed value. <del> If the first character of input_string is not "*", fail parsing. </del> <ins> If the first character of input_string is not ":", fail parsing. </ins> Discard the first character of input_string. <del> If there is not a "*" character before the end of input_string, </del> <ins> If there is not a ":" character before the end of input_string, </ins> fail parsing. Let b64_content be the result of consuming content of input_string <del> up to but not including the first instance of the character "*". </del> <ins> up to but not including the first instance of the character ":". </ins> <del> Consume the "*" character at the beginning of input_string. </del> <ins> Consume the ":" character at the beginning of input_string. </ins> If b64_content contains a character not included in ALPHA, DIGIT, "+", "/" and "=", fail parsing.
Code change:
Missed in
I'm running my SH implementation against the HTTP Archive dumps (400,000,000+ HTTP requests) to see how the from BSH parse in something like the real world. It looks like some headers are failing because AcceptAccess-Control-Allow-Origin`. If we were to use a different character to delimit Byte Sequences, we could include in Token (necessarily as a first character, as well as in the rest, I assume). Worthwhile? If so, what should we use for Byte Sequences?
(via ) already allows , but not as a first character. '%' is short in HPACK and unlikely to trigger funny handling, but maybe it will conflict with pct-encoding to start. '=' has the virtue of being already allowed. It has the drawback of causing byte array parameters to look funny ( for instance). Interestingly, it makes removal of padding easier (base64 padding is silly).
How about ? I don't' think is a good idea; if an implementation enforces padding (which we caution against, but do not prohibit), it's confusing.
Checking with NAME NAME - any issues changing byte sequence delimiters from to ?
(the only conflicting use that comes to mind ATM for is that if someone wants to refer to H2 pseudo-headers like in a field that uses tokens, they'll be out of luck. I think that's OK, because existing fields that take header names as a list-of-tokens don't refer to pseudo-headers, and new fields can be defined as lists of tokens-or-strings.)
is free

Related discussion:
text: result of running Parsing a String (parse-string) with input_string. <del> If the first character of input_string is "*", return the result </del> <ins> If the first character of input_string is ":", return the result </ins> of running Parsing a Byte Sequence (parse-binary) with input_string. If the first character of input_string is "?", return the result of running Parsing a Boolean (parse-boolean) with input_string. <del> If the first character of input_string is an ALPHA, return the result of running Parsing a Token (parse-token) with input_string. </del> <ins> If the first character of input_string is an ALPHA or "*", return the result of running Parsing a Token (parse-token) with input_string. </ins> Otherwise, the item type is unrecognized; fail parsing.
Code change:
Explicitly disallow thirteen digits before the dot.
NAME I think this is the right way to validate the number of digits in a decimal.

Related discussion:
text: If char is a DIGIT, append it to input_number. <del> Else, if type is "integer" and char is ".", append char to input_number and set type to "decimal". </del> <ins> Else, if type is "integer" and char is ".": If input_number contains more than 12 characters, fail parsing. Otherwise, append char to input_number and set type to "decimal". </ins> Otherwise, prepend char to input_string, and exit the loop.
Code change:
This patch replaces with , and corrects inadvertant usage of non-example domains in the hopes of avoiding confusion. Closes httpwg/http-extensions.
NAME mind taking a look?
Landing this. NAME if you object, let me know.
There are still com TLD remaining: and
is real domain. (currently not owned) seems better to use example domain in rfc.
Should we use the .example TLD or stay with URL It's easier to contextualize with .example, in this case webmail.example and projects.example.
SGTM in projects.example, webmail.example etc also URL are fine too.

Related discussion:
text: The term "public suffix" is defined in a note in Section 5.3 of RFC6265 as "a domain that is controlled by a public registry", and are also known as "effective top-level domains" (eTLDs).  For <del> example, "example.com"'s public suffix is "com".  User agents SHOULD </del> <ins> example, "site.example"'s public suffix is "com".  User agents SHOULD </ins> use an up-to-date public suffix list, such as the one maintained by Mozilla at PSL. An origin's "registered domain" is the origin's host's public suffix <del> plus the label to its left.  That is, for "https://www.example.com", the public suffix is "com", and the registered domain is "example.com".  This concept is defined more rigorously in PSL, and </del> <ins> plus the label to its left.  That is, for "https://www.site.example", the public suffix is "example", and the registered domain is "site.example".  This concept is defined more rigorously in PSL, and </ins> is also known as "effective top-level domain plus one" (eTLD+1). The term "request", as well as a request's "client", "current url",
Code change:
This patch replaces with , and corrects inadvertant usage of non-example domains in the hopes of avoiding confusion. Closes httpwg/http-extensions.
NAME mind taking a look?
Landing this. NAME if you object, let me know.
There are still com TLD remaining: and
is real domain. (currently not owned) seems better to use example domain in rfc.
Should we use the .example TLD or stay with URL It's easier to contextualize with .example, in this case webmail.example and projects.example.
SGTM in projects.example, webmail.example etc also URL are fine too.

Related discussion:
text: The server can alter the default scope of the cookie using the Path and Domain attributes.  For example, the server can instruct the user agent to return the cookie to every path and every subdomain of <del> example.com. </del> <ins> site.example. </ins> As shown in the next example, the server can store multiple cookies at the user agent.  For example, the server can store a session
Code change:
This patch replaces with , and corrects inadvertant usage of non-example domains in the hopes of avoiding confusion. Closes httpwg/http-extensions.
NAME mind taking a look?
Landing this. NAME if you object, let me know.
There are still com TLD remaining: and
is real domain. (currently not owned) seems better to use example domain in rfc.
Should we use the .example TLD or stay with URL It's easier to contextualize with .example, in this case webmail.example and projects.example.
SGTM in projects.example, webmail.example etc also URL are fine too.

Related discussion:
text: The Domain attribute specifies those hosts to which the cookie will be sent.  For example, if the value of the Domain attribute is <del> "example.com", the user agent will include the cookie in the Cookie header when making HTTP requests to example.com, www.example.com, and www.corp.example.com.  (Note that a leading %x2E ("."), if present, is ignored even though that character is not permitted, but a trailing %x2E ("."), if present, will cause the user agent to ignore the attribute.)  If the server omits the Domain attribute, the user agent will return the cookie only to the origin server. </del> <ins> "site.example", the user agent will include the cookie in the Cookie header when making HTTP requests to site.example, www.site.example, and www.corp.site.example.  (Note that a leading %x2E ("."), if present, is ignored even though that character is not permitted, but a trailing %x2E ("."), if present, will cause the user agent to ignore the attribute.)  If the server omits the Domain attribute, the user agent will return the cookie only to the origin server. </ins> WARNING: Some existing user agents treat an absent Domain attribute as if the Domain attribute were present and contained the current <del> host name.  For example, if example.com returns a Set-Cookie header </del> <ins> host name.  For example, if site.example returns a Set-Cookie header </ins> without a Domain attribute, these user agents will erroneously send <del> the cookie to www.example.com as well. </del> <ins> the cookie to www.site.example as well. </ins> The user agent will reject cookies unless the Domain attribute specifies a scope for the cookie that would include the origin server.  For example, the user agent will accept a cookie with a <del> Domain attribute of "example.com" or of "foo.example.com" from foo.example.com, but the user agent will not accept a cookie with a Domain attribute of "bar.example.com" or of "baz.foo.example.com". </del> <ins> Domain attribute of "site.example" or of "foo.site.example" from foo.site.example, but the user agent will not accept a cookie with a Domain attribute of "bar.site.example" or of "baz.foo.site.example". </ins> NOTE: For security reasons, many user agents are configured to reject Domain attributes that correspond to "public suffixes".  For example,
Code change:
This patch replaces with , and corrects inadvertant usage of non-example domains in the hopes of avoiding confusion. Closes httpwg/http-extensions.
NAME mind taking a look?
Landing this. NAME if you object, let me know.
There are still com TLD remaining: and
is real domain. (currently not owned) seems better to use example domain in rfc.
Should we use the .example TLD or stay with URL It's easier to contextualize with .example, in this case webmail.example and projects.example.
SGTM in projects.example, webmail.example etc also URL are fine too.

Related discussion:
text: The "SameSite" attribute limits the scope of the cookie such that it will only be attached to requests if those requests are same-site, as defined by the algorithm in same-site-requests.  For example, <del> requests for "https://example.com/sekrit-image" will attach same-site cookies if and only if initiated from a context whose "site for cookies" is "example.com". </del> <ins> requests for "https://site.example/sekrit-image" will attach same- site cookies if and only if initiated from a context whose "site for cookies" is "site.example". </ins> If the "SameSite" attribute's value is "Strict", the cookie will only be sent along with "same-site" requests.  If the value is "Lax", the
Code change:
This patch replaces with , and corrects inadvertant usage of non-example domains in the hopes of avoiding confusion. Closes httpwg/http-extensions.
NAME mind taking a look?
Landing this. NAME if you object, let me know.
There are still com TLD remaining: and
is real domain. (currently not owned) seems better to use example domain in rfc.
Should we use the .example TLD or stay with URL It's easier to contextualize with .example, in this case webmail.example and projects.example.
SGTM in projects.example, webmail.example etc also URL are fine too.

Related discussion:
text: For example, the following cookies would always be rejected: While the would be accepted if set from a secure origin (e.g. <del> "https://example.com/"), and rejected otherwise: </del> <ins> "https://site.example/"), and rejected otherwise: </ins> 4.2.
Code change:
This patch replaces with , and corrects inadvertant usage of non-example domains in the hopes of avoiding confusion. Closes httpwg/http-extensions.
NAME mind taking a look?
Landing this. NAME if you object, let me know.
There are still com TLD remaining: and
is real domain. (currently not owned) seems better to use example domain in rfc.
Should we use the .example TLD or stay with URL It's easier to contextualize with .example, in this case webmail.example and projects.example.
SGTM in projects.example, webmail.example etc also URL are fine too.

Related discussion:
text: NOTE: A "public suffix" is a domain that is controlled by a public registry, such as "com", "co.uk", and "pvt.k12.wy.us".  This step is essential for preventing attacker.com from disrupting the <del> integrity of example.com by setting a cookie with a Domain </del> <ins> integrity of site.example by setting a cookie with a Domain </ins> attribute of "com".  Unfortunately, the set of public suffixes (also known as "registry controlled domains") changes over time. If feasible, user agents SHOULD use an up-to-date public suffix
Code change:
This patch replaces with , and corrects inadvertant usage of non-example domains in the hopes of avoiding confusion. Closes httpwg/http-extensions.
NAME mind taking a look?
Landing this. NAME if you object, let me know.
There are still com TLD remaining: and
is real domain. (currently not owned) seems better to use example domain in rfc.
Should we use the .example TLD or stay with URL It's easier to contextualize with .example, in this case webmail.example and projects.example.
SGTM in projects.example, webmail.example etc also URL are fine too.

Related discussion:
text: top-level navigations. Consider the scenario in which a user reads their email at MegaCorp <del> Inc's webmail provider "https://example.com/".  They might expect that clicking on an emailed link to "https://projects.com/secret/ </del> <ins> Inc's webmail provider "https://site.example/".  They might expect that clicking on an emailed link to "https://projects.example/secret/ </ins> project" would show them the secret project that they're authorized <del> to see, but if "projects.com" has marked their session cookies as </del> <ins> to see, but if "projects.example" has marked their session cookies as </ins> "SameSite", then this cross-site navigation won't send them along with the request. "projects.com" will render a 404 error to avoid leaking secret information, and the user will be quite confused.
Code change:
URL was incomplete, leaving a number of inadvertant references to sites, or the TLD. This patch, hopefully, is less incomplete. h/t NAME and NAME for pointing this out.
WDYT, NAME

Related discussion:
text: The term "public suffix" is defined in a note in Section 5.3 of RFC6265 as "a domain that is controlled by a public registry", and are also known as "effective top-level domains" (eTLDs).  For <del> example, "site.example"'s public suffix is "com".  User agents SHOULD use an up-to-date public suffix list, such as the one maintained by Mozilla at PSL. </del> <ins> example, "site.example"'s public suffix is "example".  User agents SHOULD use an up-to-date public suffix list, such as the one maintained by Mozilla at PSL. </ins> An origin's "registered domain" is the origin's host's public suffix plus the label to its left.  That is, for "https://www.site.example",
Code change:
URL was incomplete, leaving a number of inadvertant references to sites, or the TLD. This patch, hopefully, is less incomplete. h/t NAME and NAME for pointing this out.
WDYT, NAME

Related discussion:
text: NOTE: A "public suffix" is a domain that is controlled by a public registry, such as "com", "co.uk", and "pvt.k12.wy.us".  This step <del> is essential for preventing attacker.com from disrupting the integrity of site.example by setting a cookie with a Domain attribute of "com".  Unfortunately, the set of public suffixes </del> <ins> is essential for preventing "attacker.example" from disrupting the integrity of "site.example" by setting a cookie with a Domain attribute of "example".  Unfortunately, the set of public suffixes </ins> (also known as "registry controlled domains") changes over time. If feasible, user agents SHOULD use an up-to-date public suffix list, such as the one maintained by the Mozilla project at
Code change:
URL was incomplete, leaving a number of inadvertant references to sites, or the TLD. This patch, hopefully, is less incomplete. h/t NAME and NAME for pointing this out.
WDYT, NAME

Related discussion:
text: project" would show them the secret project that they're authorized to see, but if "projects.example" has marked their session cookies as "SameSite", then this cross-site navigation won't send them along <del> with the request. "projects.com" will render a 404 error to avoid </del> <ins> with the request. "projects.example" will render a 404 error to avoid </ins> leaking secret information, and the user will be quite confused. Developers can avoid this confusion by adopting a session management