jiebi/CodeConvo huggingface dataset:
3.3.2. <del> Floats are decimal numbers with an integer and a fractional component.  The fractional component has at most six digits of precision.  Additionally, like integers, it can have no more than fifteen digits in total, which in some cases further constrains its precision. </del> <ins> Decimals are numbers with an integer and a fractional component.  The Integer component has at most 12 digits; the fractional component has at most three digits. </ins> <del> The ABNF for floats in HTTP headers is: </del> <ins> The ABNF for decimals in HTTP headers is: </ins> <del> For example, a header whose value is defined as a float could look </del> <ins> For example, a header whose value is defined as a decimal could look </ins> like: 3.3.3.
If input_item is an integer, return the result of running Serializing an Integer (ser-integer) with input_item. <del> If input_item is a float, return the result of running Serializing a Float (ser-float) with input_item. </del> <ins> If input_item is a decimal, return the result of running Serializing a Decimal (ser-decimal) with input_item. </ins> If input_item is a string, return the result of running Serializing a String (ser-string) with input_item.
4.1.5. <del> Given a float as input_float, return an ASCII string suitable for use in a HTTP header value. </del> <ins> Given a decimal_number as input_decimal, return an ASCII string suitable for use in a HTTP header value. </ins> Let output be an empty string. <del> If input_float is less than (but not equal to) 0, append "-" to </del> <ins> If input_decimal is less than (but not equal to) 0, append "-" to </ins> output. <del> Append input_float's integer component represented in base 10 </del> <ins> Append input_decimal's integer component represented in base 10 </ins> (using only decimal digits) to output; if it is zero, append "0". <del> Let integer_digits be the number of characters appended in the previous step. If integer_digits is greater than 14, fail serialisation. Let digits_avail be 15 minus integer_digits. Let fractional_digits_avail be the minimum of digits_avail and 6. </del> <ins> If the number of characters appended in the previous step is greater than 12, fail serialisation. </ins> Append "." to output. <del> If input_float's fractional component is 0, append "0" to output. </del> <ins> If input_decimal's fractional component is zero, append "0" to output. </ins> <del> Else if input_float's fractional component has fractional_digits_avail or less digits, append input_float's fractional component represented in base 10 to output. </del> <ins> Else if input_decimal's fractional component has up to three digits, append them represented in base 10 (using only decimal digits) to output. </ins> <del> Else append fractional_digits_avail digits of input_float's fractional component represented in base 10 to output, rounding to the nearest value, or to the even value if it is equidistant. </del> <ins> Otherwise, append the first three digits of input_decimal's fractional component (represented in base 10, using only decimal digits) to output, rounding the final digit to the nearest value, or to the even value if it is equidistant. </ins> Return output.
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 "float". </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. If type is "integer" and input_number contains more than 15 characters, fail parsing. <del> If type is "float" and input_number contains more than 16 </del> <ins> If type is "decimal" and input_number contains more than 16 </ins> characters, fail parsing. If type is "integer":
If the final character of input_number is ".", fail parsing. If the number of characters after "." in input_number is <del> greater than six, fail parsing. </del> <ins> greater than three, fail parsing. </ins> <del> Parse input_number as a float and let output_number be the product of the result and sign. </del> <ins> Parse input_number as a decimal number and let output_number be the product of the result and sign. </ins> Return output_number.
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.
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.
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",
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,
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
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
8.6. Cookies do not provide integrity guarantees for sibling domains (and <del> their subdomains).  For example, consider foo.example.com and bar.example.com.  The foo.example.com server can set a cookie with a Domain attribute of "example.com" (possibly overwriting an existing "example.com" cookie set by bar.example.com), and the user agent will include that cookie in HTTP requests to bar.example.com.  In the worst case, bar.example.com will be unable to distinguish this cookie from a cookie it set itself.  The foo.example.com server might be able to leverage this ability to mount an attack against bar.example.com. </del> <ins> their subdomains).  For example, consider foo.site.example and bar.site.example.  The foo.site.example server can set a cookie with a Domain attribute of "site.example" (possibly overwriting an existing "site.example" cookie set by bar.site.example), and the user agent will include that cookie in HTTP requests to bar.site.example. In the worst case, bar.site.example will be unable to distinguish this cookie from a cookie it set itself.  The foo.site.example server might be able to leverage this ability to mount an attack against bar.site.example. </ins> Even though the Set-Cookie header supports the Path attribute, the Path attribute does not provide any integrity protection because the user agent will accept an arbitrary Path attribute in a Set-Cookie header.  For example, an HTTP response to a request for <del> http://example.com/foo/bar can set a cookie with a Path attribute of </del> <ins> http://site.example/foo/bar can set a cookie with a Path attribute of </ins> "/qux".  Consequently, servers SHOULD NOT both run mutually distrusting services on different paths of the same host and use cookies to store security-sensitive information. An active network attacker can also inject cookies into the Cookie <del> header sent to https://example.com/ by impersonating a response from http://example.com/ and injecting a Set-Cookie header.  The HTTPS server at example.com will be unable to distinguish these cookies </del> <ins> header sent to https://site.example/ by impersonating a response from http://site.example/ and injecting a Set-Cookie header.  The HTTPS server at site.example will be unable to distinguish these cookies </ins> from cookies that it set itself in an HTTPS response.  An active network attacker might be able to leverage this ability to mount an <del> attack against example.com even if example.com uses HTTPS </del> <ins> attack against site.example even if site.example uses HTTPS </ins> exclusively. Servers can partially mitigate these attacks by encrypting and signing the contents of their cookies.  However, using cryptography does not mitigate the issue completely because an attacker can replay <del> a cookie he or she received from the authentic example.com server in </del> <ins> a cookie he or she received from the authentic site.example server in </ins> the user's session, with unpredictable results. Finally, an attacker might be able to force the user agent to delete
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.
contained in the set-cookie-string, and the unparsed-attributes is the empty string. <del> If the name-value-pair string lacks a %x3D ("=") character, ignore the set-cookie-string entirely. </del> <ins> If the name-value-pair string lacks a %x3D ("=") character, then the name string is empty, and the value string is the value of name-value-pair. </ins> <del> The (possibly empty) name string consists of the characters up to, but not including, the first %x3D ("=") character, and the (possibly empty) value string consists of the characters after the first %x3D ("=") character. </del> <ins> Otherwise, the name string consists of the characters up to, but not including, the first %x3D ("=") character, and the (possibly empty) value string consists of the characters after the first %x3D ("=") character. </ins> Remove any leading or trailing WSP characters from the name string and the value string. <del> If the name string is empty, ignore the set-cookie-string entirely. </del> <ins> If both the name string and the value string are empty, ignore the set-cookie-string entirely. </ins> The cookie-name is the name string, and the cookie-value is the value string.
3.1.2. Parameters are an ordered map of key-values pairs that are associated <del> with an item (item) or inner-list (inner-list).  The keys are required to be unique within the scope of a map of parameters, and the values are bare items (i.e., they themselves cannot be parameterised; see item). </del> <ins> with an item (item) or inner-list (inner-list).  The keys are unique within the scope of a map of parameters, and the values are bare items (i.e., they themselves cannot be parameterised; see item). </ins> The ABNF for parameters in HTTP headers is:
Dictionaries are ordered maps of name-value pairs, where the names are short, textual strings and the values are items (item) or arrays of items, both of which can be parameterised (param).  There can be <del> zero or more members, and their names are required to be unique in the scope of the dictionary they occur within. </del> <ins> zero or more members, and their names are unique in the scope of the dictionary they occur within. </ins> Implementations MUST provide access to dictionaries both by index and by name.  Specifications MAY use either means of accessing the
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",
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
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
types, and constraints upon them.  For example, a header defined as a List might have all Integer members, or a mix of types; a header defined as an Item might allow only Strings, and additionally only <del> strings beginning with the letter "Q". </del> <ins> strings beginning with the letter "Q".  Likewise, inner lists are only valid when a header definition explicitly allows them. </ins> When Structured Headers parsing fails, the header is ignored (see text-parse); in most situations, violating header-specific
received, it will by default be ignored.  If the header requires different error handling, this should be explicitly specified. <del> However, both Items and Inner Lists allow parameters as an </del> <ins> However, both items and inner lists allow parameters as an </ins> extensibility mechanism; this means that values can later be extended to accommodate more information, if need be.  As a result, header specifications are discouraged from defining the presence of an unrecognised parameter as an error condition. <del> Conversely, inner lists are only valid when a header definition explicitly allows them. </del> <ins> To help assure that this extensibility is available in the future, and to encourage consumers to use a fully capable Structured Headers parser, a header definition can specify that "grease" parameters be added by senders.  For example, a specification could stipulate that all parameters beginning with the letter 'q' are reserved for this use. </ins> Note that a header field definition cannot relax the requirements of this specification because doing so would preclude handling by
4.1.5. <del> Given a decimal_number as input_decimal, return an ASCII string </del> <ins> Given a decimal number as input_decimal, return an ASCII string </ins> suitable for use in a HTTP field value. <ins> If input_decimal is not a decimal number, fail serialisation. If input_decimal has more than three significant digits to the right of the decimal point, round it to three decimal places, rounding the final digit to the nearest value, or to the even value if it is equidistant. If input_decimal has more than 12 significant digits to the left of the decimal point after rounding, fail serialisation. </ins> Let output be an empty string. If input_decimal is less than (but not equal to) 0, append "-" to
Append input_decimal's integer component represented in base 10 (using only decimal digits) to output; if it is zero, append "0". <del> If the number of characters appended in the previous step is greater than 12, fail serialisation. </del> Append "." to output. If input_decimal's fractional component is zero, append "0" to output. <del> Else if input_decimal's fractional component has up to three digits, append them represented in base 10 (using only decimal </del> <ins> Otherwise, append the significant digits of input_decimal's fractional component represented in base 10 (using only decimal </ins> digits) to output. <del> Otherwise, append the first three digits of input_decimal's fractional component (represented in base 10, using only decimal digits) to output, rounding the final digit to the nearest value, or to the even value if it is equidistant. </del> Return output. 4.1.6.
clear persisted opt-in preferences when any one of site data, browsing history, browsing cache, cookies, or similar, are cleared. <del> 5. While HTTP header compression schemes reduce the cost of adding HTTP header fields, sending Client Hints to the server incurs an increase in request byte size.  Servers SHOULD take that into account when opting in to receive Client Hints, and SHOULD NOT opt-in to receive hints unless they are to be used for content adaptation purposes. Due to request byte size increase, features relying on this document to define Client Hints MAY consider restricting sending those hints to certain request destinations FETCH, where they are more likely to be useful. 5.1. </del> <ins> 4.2. </ins> Deployment of new request headers requires several considerations:
and from those without.  This might be used to reveal which Client Hints are in use, allowing researchers to further analyze that use. <ins> 5. While HTTP header compression schemes reduce the cost of adding HTTP header fields, sending Client Hints to the server incurs an increase in request byte size.  Servers SHOULD take that into account when opting in to receive Client Hints, and SHOULD NOT opt-in to receive hints unless they are to be used for content adaptation purposes. Due to request byte size increase, features relying on this document to define Client Hints MAY consider restricting sending those hints to certain request destinations FETCH, where they are more likely to be useful. </ins> 6. This document defines the "Accept-CH" HTTP response field, and
the server. An origin can use the Priority response header field to indicate its <del> view on how an HTTP response should be prioritized.  When forwarding an HTTP response with the Priority response header field, an intermediary can use the parameters being found in that response instead of those found in the request. </del> <ins> view on how an HTTP response should be prioritized.  An intermediary that forwards an HTTP response can use the parameters found in the Priority response header field, in combination with the client Priority request header field, as input to its prioritization process.  No guidance is provided for merging priorities, this is left as an implementation decision. </ins> Absence of a priority parameter in an HTTP response indicates the server's disinterest in changing the client-provided value.  This is