jiebi/CodeConvo huggingface dataset:
Extra Parameters: <del> details: a sh-string containing the checksum or SPKI of the certificate received from the next hop. Recommended HTTP status code: 502 3.26. Name: tls_unexpected_peer_identity Description: The intermediary received peer certificate with unexpected identity (e.g., Subject Alternative Name doesn't match) during TLS handshake with the next hop. </del> <ins> identity: a sh-string containing a comma-separated list of Subject Alternative Names from the certificate received from the next hop. </ins> <del> Extra Parameters: </del> <ins> sha256: a sh-string containing the hex-encoded SHA-256 of the certificate received from the next hop. </ins> <del> details: a sh-string containing the identity of the next hop. </del> <ins> spki: a sh-string containing the base64-encoded SHA-256 of the Subject Public Key Info (SPKI) from the certificate received from the next hop. </ins> Recommended HTTP status code: 502 <del> 3.27. </del> <ins> 3.26. </ins> Name: tls_missing_proxy_certificate
Description: The MD5 algorithm, as specified in RFC1321.  The output of this algorithm is encoded using the base64 encoding <del> RFC4648.  The MD5 algorithm is NOT RECOMMENDED as it's now </del> <ins> RFC4648.  The MD5 algorithm MUST NOT be used as it's now </ins> vulnerable to collision attacks CMU-836068. Reference: RFC1321, RFC4648, this document. <del> Status: obsoleted </del> <ins> Status: deprecated </ins>
9.7. <del> The status has been updated to "obsoleted" for both "SHA" and "MD5", and their descriptions states that those algorithms are NOT RECOMMENDED. </del> <ins> The status of "MD5" has been updated to "deprecated", and its description states that this algoritm MUST NOT be used. The status of "SHA" has been updated to "obsoleted", and its description states that this algorithm is NOT RECOMMENDED. </ins> The status for all other algorithms have been updated to "standard".
<del> Description: The SHA-256 algorithm FIPS180-3.  The output of this algorithm is encoded using the base64 encoding RFC4648. </del> <ins> Description: The SHA-256 algorithm RFC6234.  The output of this algorithm is encoded using the base64 encoding RFC4648. </ins> <del> Reference: FIPS180-3, RFC4648, this document. </del> <ins> Reference: RFC6234, RFC4648, this document. </ins> Status: standard <del> Description: The SHA-512 algorithm FIPS180-3.  The output of this algorithm is encoded using the base64 encoding RFC4648. </del> <ins> Description: The SHA-512 algorithm RFC6234.  The output of this algorithm is encoded using the base64 encoding RFC4648. </ins> <del> Reference: FIPS180-3, RFC4648, this document. </del> <ins> Reference: RFC6234, RFC4648, this document. </ins> Status: standard
<del> Description: The SHA-1 algorithm FIPS180-1.  The output of this </del> <ins> Description: The SHA-1 algorithm RFC3174.  The output of this </ins> algorithm is encoded using the base64 encoding RFC4648.  The SHA algorithm is NOT RECOMMENDED as it's now vulnerable to collision attacks IACR-2019-459. <del> Reference: FIPS180-3, RFC4648, this document. </del> <ins> Reference: RFC3174, RFC6234, RFC4648, this document. </ins> Status: obsoleted
9.5. <ins> This memo updates the "ADLER32" digest algorithm in the HTTP Digest Algorithm Values [8] registry: Digest Algorithm: ADLER32 Description: The ADLER32 algorithm is a checksum specified in RFC1950 "ZLIB Compressed Data Format".  The 32-bit output is encoded in hexadecimal (using between 1 and 8 ASCII characters from 0-9, A-F, and a-f; leading 0's are allowed).  For example, ADLER32=03da0195 and ADLER32=3DA0195 are both valid checksums for the 4-byte message "Wiki".  This algorithm is obsoleted and SHOULD NOT be used. Status: obsoleted 9.6. </ins> This memo registers the "ID-SHA-256" digest algorithm in the HTTP <del> Digest Algorithm Values [8] registry: </del> <ins> Digest Algorithm Values [9] registry: </ins> Digest Algorithm: ID-SHA-256
because it is not clear whether they will be used, and sending them impacts both performance and privacy. <del> This document defines two response headers, Accept-CH and Accept-CH- Lifetime, that servers can use to advertise their use of request headers for proactive content negotiation, along with a set of guidelines for the creation of such headers, colloquially known as "Client Hints." </del> <ins> This document defines an Accept-CH response header that servers can use to advertise their use of request headers for proactive content negotiation, along with a set of guidelines for the creation of such headers, colloquially known as "Client Hints." </ins> Note to Readers
There are thousands of different devices accessing the web, each with different device capabilities and preference information.  These device capabilities include hardware and software characteristics, as <del> well as dynamic user and client preferences. One way to infer some of these capabilities is through User-Agent (Section 5.5.3 of RFC7231) header field detection against an established database of client signatures.  However, this technique requires acquiring such a database, integrating it into the serving path, and keeping it up to date.  However, even once this infrastructure is deployed, user agent sniffing has numerous limitations: User agent detection cannot reliably identify all static variables User agent detection cannot infer any dynamic client preferences User agent detection requires an external device database User agent detection is not cache friendly A popular alternative strategy is to use HTTP cookies (RFC6265) to communicate some information about the user agent.  However, this approach is also not cache friendly, bound by same origin policy, and often imposes additional client-side latency by requiring JavaScript execution to create and manage HTTP cookies. </del> <ins> well as dynamic user and client preferences.  Applications that want to allow the server to optimize content delivery and user experience based on such capabilities have, historically, had to rely on passive identification (e.g., by matching User-Agent (Section 5.5.3 of RFC7231) header field against an established database of client signatures), used HTTP cookies and URL parameters, or use some combination of these and similar mechanisms to enable ad hoc content negotiation. Such techniques are expensive to setup and maintain, are not portable across both applications and servers, and make it hard to reason for both client and server about which data is required and is in use during the negotiation: User agent detection cannot reliably identify all static variables, cannot infer dynamic client preferences, requires external device database, is not cache friendly, and is reliant on a passive fingerprinting surface. Cookie based approaches are not portable across applications and servers, impose additional client-side latency by requiring JavaScript execution, and are not cache friendly. URL parameters, similar to cookie based approaches, suffer from lack of portability, and are hard to deploy due to a requirement to encode content negotiation data inside of the URL of each resource. </ins> Proactive content negotiation (Section 3.4.1 of RFC7231) offers an alternative approach; user agents use specified, well-defined request
This document defines a new response header, Accept-CH, that allows an origin server to explicitly ask that clients send these headers in <del> requests, for a period of time bounded by the Accept-CH-Lifetime response header.  It also defines guidelines for content negotiation </del> <ins> requests.  It also defines guidelines for content negotiation </ins> mechanisms that use it, colloquially referred to as Client Hints. Client Hints mitigate the performance concerns by assuring that
will use that infrastructure.  Those features will be defined in their respective specifications. <del> This document does not supersede or replace the User-Agent header field.  Existing device detection mechanisms can continue to use both mechanisms if necessary.  By advertising user agent capabilities within a request header field, Client Hints allow for cache friendly and proactive content negotiation. </del> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
required to be unique within the scope of the dictionary they occur within. <ins> Each member of the dictionary can also have associated parameters - an ordered map of key-value pairs where the keys are short, textual strings and the values are items (item).  There can be zero or more parameters on a member, and their keys are required to be unique within that scope. </ins> Implementations MUST provide access to dictionaries both by index and by name.  Specifications MAY use either means of accessing the members.
A dictionary with a member whose value is an inner-list of tokens: <del> Typically, a header field specification will define the semantics of individual member names, as well as whether their presence is </del> <ins> A dictionary with a mix of singular and list values, some with parameters: Typically, a header field specification will define the semantics using individual member names, as well as whether their presence is </ins> required or optional.  Recipients MUST ignore names that are undefined or unknown, unless the header field's specification specifically disallows them.
Append mem_value to output. <del> For each parameter in parameters: Append ";" to output. Let name be the result of applying Serializing a Key (ser- key) to parameter's param-name. Append name to output. If parameter has a param-value: Let value be the result of applying Serializing an Item (ser-item) to parameter's param-value. Append "=" to output. Append value to output. </del> <ins> Append the result of Serializing Parameters ser-params with parameters to output. </ins> If more members remain in input_plist:
4.1.1.2. <ins> Given an ordered dictionary parameters: Let output be an empty string. For each parameter in parameters: Append ";" to output. Let name be the result of applying Serializing a Key (ser-key) to parameter's param-name. Append name to output. If parameter has a param-value: Let value be the result of applying Serializing an Item (ser- item) to parameter's param-value. Append "=" to output. Append value to output. Return output. 4.1.1.3. </ins> Given a key as input_key: If input_key is not a sequence of characters, or contains
Let output be an empty string. <del> For each member mem of input_dictionary: </del> <ins> For each (member, parameters) of input_dictionary: </ins> Let name be the result of applying Serializing a Key (ser-key) <del> to mem's member-name. </del> <ins> to member's member-name. </ins> Append name to output. Append "=" to output. <del> If mem is an array, let value be the result of applying Serialising an Inner List (ser-innerlist) to mem. </del> <ins> If member is an array, let value be the result of applying Serialising an Inner List (ser-innerlist) to member. </ins> Otherwise, let value be the result of applying Serializing an <del> Item (ser-item) to mem. </del> <ins> Item (ser-item) to member. </ins> Append value to output. <ins> Append the result of Serializing Parameters ser-params with parameters to output. </ins> If more members remain in input_dictionary: Append a COMMA to output.
Consume the first character of input_string; if it is not "=", fail parsing. <del> If the first character of input_string is "(", let this_value be the result of running Parsing an Inner List (parse- innerlist) with input_string. Else, let this_value be the result of running Parsing an Item (parse-item) with input_string. </del> <ins> Let member be the result of running Parsing a Parameterized Member from Text (parse-param) with input_string. </ins> <del> Add name this_key with value this_value to dictionary. </del> <ins> Add name this_key with value member to dictionary. </ins> Discard any leading OWS from input_string.
3.5. <del> Floats are integers with a fractional part, that can be stored as IEEE 754 double precision numbers (binary64) (IEEE754). </del> <ins> Floats are decimal numbers with an integer and a fractional part. The fractional part 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. </ins> The ABNF for floats in textual HTTP headers is:
TLS 1.3 RFC8446 updates TLS 1.2 to remove renegotiation in favor of separate post-handshake authentication and key update mechanisms. The former shares the same problems with multiplexed protocols, but <del> has a different name.  This makes it ambiguous whether post-handshake authentication is allowed in TLS 1.3. </del> <ins> the prohibition in HTTP/2 only applies to TLS 1.2 renegotiation. </ins> <del> This document clarifies that the prohibition applies to post- handshake authentication but not to key updates. </del> <ins> This document updates HTTP/2 to similarly forbid TLS 1.3 post- handshake authentication. </ins> 2.
3. <del> The prohibition on renegotiation in section 9.2.1 of RFC7540 additionally applies to TLS 1.3 post-handshake authentication. </del> HTTP/2 servers MUST NOT send post-handshake TLS 1.3 CertificateRequest messages.  HTTP/2 clients MUST treat TLS 1.3 post- handshake authentication as a connection error (see section 5.4.1 of
4. <del> Section 9.2.1 of RFC7540 does not extend to TLS 1.3 KeyUpdate messages.  HTTP/2 implementations MUST support key updates when TLS 1.3 is negotiated. </del> <ins> RFC8446 defines two other messages that are exchanged after the handshake is complete, KeyUpdate and NewSessionTicket. KeyUpdate messages only affect TLS itself and do not require any interaction with the application protocol.  HTTP/2 implementations MUST support key updates when TLS 1.3 is negotiated. NewSessionTicket messages are also permitted.  Though these interact with HTTP when early data is enabled, these interactions are defined in RFC8470 and allowed for in the design of HTTP/2. Unless the use of a new type of TLS message depends on an interaction with the application layer protocol, that TLS message can be sent after the handshake completes. </ins> 5. <del> This document clarifies how to use HTTP/2 with TLS 1.3 and resolves a compatibility concern when supporting post-handshake authentication with HTTP/1.1.  This lowers the barrier for deploying TLS 1.3, a major security improvement over TLS 1.2.  Permitting key updates allows key material to be refreshed in long-lived HTTP/2 connections. </del> <ins> This document resolves a compatibility concern between HTTP/2 and TLS 1.3 when supporting post-handshake authentication with HTTP/1.1. This lowers the barrier for deploying TLS 1.3, a major security improvement over TLS 1.2. </ins> 6.
HTTP/2 RFC7540 multiplexes multiple HTTP requests over a single connection, which is incompatible with the mechanism above.  Clients cannot correlate the certificate request with the HTTP request which <del> triggered it.  Thus, section 9.2.1 of RFC7540 forbids renegotiation. </del> <ins> triggered it.  Thus, Section 9.2.1 of RFC7540 forbids renegotiation. </ins> TLS 1.3 RFC8446 updates TLS 1.2 to remove renegotiation in favor of separate post-handshake authentication and key update mechanisms.
HTTP/2 servers MUST NOT send post-handshake TLS 1.3 CertificateRequest messages.  HTTP/2 clients MUST treat TLS 1.3 post- <del> handshake authentication as a connection error (see section 5.4.1 of </del> <ins> handshake authentication as a connection error (see Section 5.4.1 of </ins> RFC7540) of type PROTOCOL_ERROR. RFC7540 permitted renegotiation before the HTTP/2 connection preface
7.1.1. <ins> Request: Response: </ins> 7.1.2. As there is no content coding applied, the "sha-256" and the "id-sha- 256" digest-values are the same. <ins> Request: Response: </ins> 7.1.3. <ins> Request: Response: </ins> 7.1.4. Digest can be used in requests too.  Returned value depends on the representation metadata header fields. <ins> Request: Response: </ins> 7.1.5. Request "Digest" value is calculated on the enclosed payload.
The client requests a digest, preferring sha.  The server is free to reply with sha-256 anyway. <ins> Request: Response: </ins> 7.2.2. The client requests a sha digest only.  The server is currently free to reply with a Digest containing an unsupported algorithm <ins> Request: Response: </ins> 7.2.3. The client requests a sha Digest, the server advises for sha-256 and sha-512 <ins> Request: Response: </ins> ... 8.
RFC7230. The definitions "representation", "selected representation", <del> "representation data", "representation metadata" and "payload body" </del> <ins> "representation data", "representation metadata", and "payload body" </ins> in this document are to be interpreted as described in RFC7230 and RFC7231. <ins> The definition "validator" in this document is to be interpreted as described in Section 7.2 of RFC7231. </ins> 2. To avoid inconsistencies, an integrity mechanism for HTTP messages
calculated using the representation data that would have been enclosed in the payload body if the same request had been a GET. <del> Digest can be used in requests too.  Returned value depends on the representation metadata header fields. </del> <ins> Digest can be used in requests too. The "Digest" value depends on the representation metadata. </ins> A Digest header field MAY contain multiple representation-data-digest values.  This could be useful for responses expected to reside in
9.4. <del> Digest can be used in requests too.  Returned value depends on the representation metadata header fields. </del> <ins> The request contains a "Digest" header calculated on the enclosed representation. It also includes an "Accept-Encoding: br" header field that advertises the client supports brotli encoding. The response includes a "Content-Encoding: br" that indicates the selected representation is brotli encoded.  The "Digest" field-value is therefore different compared to the request. </ins> Request:
3.2. Dictionaries are ordered maps of name-value pairs, where the names <del> are short, textual strings and the values are items (item) or arrays of items, both of which can be parameterised (param).  There can be zero or more members, and their names are required to be unique within the scope of the dictionary they occur within. </del> <ins> are short, textual strings and the values can be items (item) or arrays of items, both of which can be parameterised (param).  There can be zero or more members, and their names are required to be unique within 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
whitespace, while names and values are separated by "=" (without whitespace).  For example: <ins> Members whose value is Boolean true MUST omit that value when serialised, unless it has parameters.  For example, here both "b" and "c" are true, but "c"'s value is serialised because it has parameters: Note that this requirement is only on serialisation; parsers are still required to correctly handle the true value when it appears in dictionary values. </ins> A dictionary with a member whose value is an inner-list of tokens: A dictionary with a mix of singular and list values, some with
Append the result of running Serializing a Key (ser-key) with member's member_name to output. <del> Append "=" to output. </del> <ins> If member_value is not Boolean true or parameters is not empty: </ins> <del> If member_value is an array, append the result of running Serialising an Inner List (ser-innerlist) with (member_value, parameters) to output. </del> <ins> Append "=" to output. </ins> <del> Otherwise, append the result of running Serializing an Item (ser-item) with (member_value, parameters) to output. </del> <ins> If member_value is an array, append the result of running Serialising an Inner List (ser-innerlist) with (member_value, parameters) to output. Otherwise, append the result of running Serializing an Item (ser-item) with (member_value, parameters) to output. </ins> If more members remain in input_dictionary:
If dictionary already contains the name this_key, there is a duplicate; fail parsing. <del> Consume the first character of input_string; if it is not "=", fail parsing. </del> <ins> If the first character of input_string is "=": Consume the first character of input_string. Let member be the result of running Parsing an Item or Inner List (parse-item-or-list) with input_string. Otherwise: Let value be Boolean true. Let parameters be an empty, ordered map. </ins> <del> Let member be the result of running Parsing an Item or Inner List (parse-item-or-list) with input_string. </del> <ins> Let member be the tuple (value, parameters). </ins> Add name this_key with value member to dictionary.
Append the result of running Serializing a Key (ser-key) with member's member_name to output. <ins> If member_value is not Boolean true or parameters is not empty: </ins> Append "=" to output. <del> If member_value is an array, append the result of running Serialising an Inner List (ser-innerlist) with (member_value, parameters) to output. </del> <ins> If member_value is an array, append the result of running Serialising an Inner List (ser-innerlist) with (member_value, parameters) to output. </ins> <del> Otherwise, append the result of running Serializing an Item (ser-item) with (member_value, parameters) to output. </del> <ins> Otherwise, append the result of running Serializing an Item (ser-item) with (member_value, parameters) to output. </ins> <del> If more members remain in input_dictionary: </del> <ins> If more members remain in input_dictionary: </ins> <del> Append a COMMA to output. </del> <ins> Append a COMMA to output. </ins> <del> Append a single WS to output. </del> <ins> Append a single WS to output. </ins> Return output.
A complete field section consists of either: <del> Field compression is stateful.  One compression context and one decompression context are used for the entire connection.  A decoding error in a field block MUST be treated as a ConnectionErrorHandler of type COMPRESSION_ERROR. </del> Each field block is processed as a discrete unit.  Field blocks MUST be transmitted as a contiguous sequence of frames, with no interleaved frames of any other type or from any other stream.  The
MUST terminate the connection with a ConnectionErrorHandler of type COMPRESSION_ERROR if it does not decompress a field block. <ins> A decoding error in a field block MUST be treated as a ConnectionErrorHandler of type COMPRESSION_ERROR. 4.3.1. Field compression is stateful.  One compression context and one decompression context are used for the entire connection. COMPRESSION defines the dynamic table, which is the primary state that is used for field compression. The dynamic table has a maximum size that is set by a decoder using the SETTINGS_HEADER_TABLE_SIZE setting; see SettingValues.  The encoder can set the dynamic table to any size up to the maximum value set by the decoder.  The encoder declares the size of the dynamic table with a Dynamic Table Size Update instruction (COMPRESSION). The encoder at both client and server is initialized with a dynamic table size of 4,096 bytes, the initial value of the SETTINGS_HEADER_TABLE_SIZE setting. Any change to the maximum value set by the decoder takes effect when the encoder SettingsSync.  The first field block sent by an encoder after a change in SETTINGS_HEADER_TABLE_SIZE starts with at least one Dynamic Table Size Update instruction; see COMPRESSION.  An encoder sends a Dynamic Table Size Update instruction after acknowledging a change of SETTINGS_HEADER_TABLE_SIZE even if it is not changing the size of the dynamic table or an increase to the maximum size is subsequently reverted before the field block is sent.  An encoder MAY treat the absence of Dynamic Table Size Update instructions in a field block following an acknowledgment of a change to SETTINGS_HEADER_TABLE_SIZE as a ConnectionErrorHandler of type COMPRESSION_ERROR. </ins> 5. A "stream" is an independent, bidirectional sequence of frames