jiebi/CodeConvo huggingface dataset:
Because this draft permits certificates to be exchanged at the HTTP framing layer instead of the TLS layer, several certificate-related errors which are defined at the TLS layer might now occur at the HTTP <del> framing layer.  In this section, those errors are restated and added to the HTTP/2 error code registry. </del> <ins> framing layer. </ins> <del> A certificate was corrupt, contained signatures that did not verify correctly, etc. </del> <ins> There are two classes of errors which might be encountered, and they are handled differently. </ins> <del> A certificate was of an unsupported type or did not contain required extensions </del> <ins> 4.1. </ins> <del> A certificate was revoked by its signer </del> <ins> This category of errors could indicate a peer failing to follow restrictions in this document, or might indicate that the connection is not fully secure.  These errors are fatal to stream or connection, as appropriate. </ins> <del> A certificate has expired or is not currently valid </del> <ins> More certificates were used on a request than were requested </ins> <del> Any other certificate-related error </del> <ins> A CERTIFICATE_NEEDED frame was received by a peer which did not indicate support for this extension. </ins> <del> More certificates were used on a request than were requested </del> <ins> An exported authenticator could not be validated. 4.2. </ins> <del> As described in RFC7540, implementations MAY choose to treat a stream error as a connection error at any time.  Of particular note, a stream error cannot occur on stream 0, which means that implementations cannot send non-session errors in response to "CERTIFICATE_REQUEST", and "CERTIFICATE" frames.  Implementations which do not wish to terminate the connection MAY either send relevant errors on any stream which references the failing certificate in question or process the requests as unauthenticated and provide error information at the HTTP semantic layer. </del> <ins> Unacceptable certificates (expired, revoked, or insufficient to satisfy the request) are not treated as stream or connection errors. This is typically not an indication of a protocol failure.  Servers SHOULD process requests with the indicated certificate, likely resulting in a "4XX"-series status code in the response.  Clients SHOULD establish a new connection in an attempt to reach an authoritative server. </ins> 5.
current connection, but MAY use the ORIGIN frame RFC8336 to indicate that not all covered origins will be served. <ins> Certificates supplied by clients MUST NOT be considered by servers when processing a request unless the client explicitly authorizes their use.  Clients MAY send "USE_CERTIFICATE" frame with the "UNSOLICITED" flag set to indicate that an available certificate should be considered on a new request. </ins> Likewise, a party can supply a "CERTIFICATE_REQUEST" that outlines parameters of a certificate they might request in the future.  Upon receipt of a "CERTIFICATE_REQUEST", endpoints SHOULD provide a
If a client receives a "PUSH_PROMISE" referencing an origin for which it has not yet received the server's certificate, this is a stream <del> error (see section 8.2 of RFC7540).  To avoid this, servers MUST supply the associated certificates before pushing resources from a different origin. </del> <ins> error on the push stream; see section 8.2 of RFC7540.  To avoid this, servers MUST supply the associated certificates before pushing resources from a different origin. </ins> 2.3.2.
Description: The SHA-1 algorithm RFC3174.  The output of this algorithm is encoded using the base64 encoding RFC4648.  The <del> SHA algorithm is NOT RECOMMENDED as it's now vulnerable to collision attacks IACR-2019-459. </del> <ins> SHA algorithm MUST NOT be used as it's now vulnerable to collision attacks IACR-2020-014. </ins> Reference: RFC3174, RFC6234, RFC4648, this document. <del> Status: obsoleted </del> <ins> Status: deprecated </ins>
1.2. <del> The concept of "selected representation" defined in Section 6 of I- D.ietf-httpbis-semantics makes RFC3230 definitions inconsistent with current HTTP semantics.  This document updates the "Digest" and "Want-Digest" field definitions to align with I-D.ietf-httpbis- semantics concepts. </del> <ins> The concept of "selected representation" defined in Section 6 of SEMANTICS makes RFC3230 definitions inconsistent with current HTTP semantics.  This document updates the "Digest" and "Want-Digest" field definitions to align with SEMANTICS concepts. </ins> Basing "Digest" on the selected representation makes it straightforward to apply it to use-cases where the transferred data does require some sort of manipulation to be considered a representation, or conveys a partial representation of a resource eg. <del> Range Requests (see Section 8.3 of I-D.ietf-httpbis-semantics). </del> <ins> Range Requests (see Section 8.3 of SEMANTICS). </ins> Changes are semantically compatible with existing implementations and better cover both the request and response cases.
different digest values. To allow both parties to exchange a Digest of a representation with <del> no content codings (see Section 6.1.2 of I-D.ietf-httpbis-semantics) two more algorithms are added ("ID-SHA-256" and "ID-SHA-512"). </del> <ins> no content codings (see Section 6.1.2 of SEMANTICS) two more algorithms are added ("ID-SHA-256" and "ID-SHA-512"). </ins> 1.3.
This document uses the Augmented BNF defined in RFC5234 and updated by RFC7405 along with the "#rule" extension defined in Section 4 of <del> I-D.ietf-httpbis-semantics. </del> <ins> SEMANTICS. </ins> The definitions "representation", "selected representation", "representation data", "representation metadata", and "payload body" <del> in this document are to be interpreted as described in I-D.ietf- httpbis-semantics. </del> <ins> in this document are to be interpreted as described in SEMANTICS. </ins> The definition "validator fields" in this document is to be <del> interpreted as described in Section 10.2 of I-D.ietf-httpbis- semantics. </del> <ins> interpreted as described in Section 10.2 of SEMANTICS. </ins> 2. The representation digest is an integrity mechanism for HTTP resources which uses a checksum that is calculated independently of the payload body and message body.  It uses the representation data <del> (see Section 6.1 of I-D.ietf-httpbis-semantics), that can be fully or partially contained in the message body, or not contained at all: </del> <ins> (see Section 6.1 of SEMANTICS), that can be fully or partially contained in the message body, or not contained at all: </ins> This takes into account the effect of the HTTP semantics on the messages; for example the payload body can be affected by Range
The resource is specified by the effective request URI and any "validator field" contained in the message. <del> The relationship between Content-Location (see Section 6.2.5 of I- D.ietf-httpbis-semantics) and Digest is demonstrated in post-not- request-uri.  A comprehensive set of examples showing the impacts of representation metadata, payload transformations and HTTP methods on Digest is provided in examples-unsolicited and examples-solicited. </del> <ins> The relationship between Content-Location (see Section 6.2.5 of SEMANTICS) and Digest is demonstrated in post-not-request-uri.  A comprehensive set of examples showing the impacts of representation metadata, payload transformations and HTTP methods on Digest is provided in examples-unsolicited and examples-solicited. </ins> A Digest field MAY contain multiple representation-data-digest values.  This could be useful for responses expected to reside in
computation.  For some algorithms, one or more parameters can be supplied. <del> The BNF for "parameter" is defined in Section 4.4.1.4 of I-D.ietf- httpbis-semantics.  All digest-algorithm values are case-insensitive. </del> <ins> The BNF for "parameter" is defined in Section 4.4.1.4 of SEMANTICS. All digest-algorithm values are case-insensitive. </ins> The Internet Assigned Numbers Authority (IANA) acts as a registry for digest-algorithm values.  The registry contains the tokens listed
Append the result of running Serializing a Key (ser-key) with member's member_name to output. <del> If member_value is Boolean true: </del> <ins> If member_value is Boolean true: </ins> <del> Append the result of running Serializing Parameters (ser- params) with parameters to output. </del> <ins> Append the result of running Serializing Parameters (ser- params) with parameters to output. </ins> <del> Otherwise: </del> <ins> Otherwise: </ins> <del> Append "=" to output. </del> <ins> Append "=" to output. </ins> <del> If member_value is an array, append the result of running Serializing an Inner List (ser-innerlist) with (member_value, parameters) to output. </del> <ins> If member_value is an array, append the result of running Serializing 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 "," to output. </del> <ins> Append "," to output. </ins> <del> Append a single SP to output. </del> <ins> Append a single SP to output. </ins> Return output.
behaviors, and the Augmented Backus-Naur Form (ABNF) notation of RFC5234 to illustrate expected syntax in HTTP header fields.  In doing so, it uses the VCHAR, SP, DIGIT, ALPHA and DQUOTE rules from <del> RFC5234.  It also includes the tchar rule from RFC7230. </del> <ins> RFC5234.  It also includes the tchar and OWS rules from RFC7230. </ins> When parsing from HTTP fields, implementations MUST have behavior that is indistinguishable from following the algorithms.  If there is
Append the result of running Parsing an Item or Inner List (parse-item-or-list) with input_string to members. <del> Discard any leading SP characters from input_string. </del> <ins> Discard any leading OWS characters from input_string. </ins> If input_string is empty, return members. Consume the first character of input_string; if it is not ",", fail parsing. <del> Discard any leading SP characters from input_string. </del> <ins> Discard any leading OWS characters from input_string. </ins> If input_string is empty, there is a trailing comma; fail parsing.
dictionary already contains a name this_key (comparing character-for-character), overwrite its value. <del> Discard any leading SP characters from input_string. </del> <ins> Discard any leading OWS characters from input_string. </ins> If input_string is empty, return dictionary. Consume the first character of input_string; if it is not ",", fail parsing. <del> Discard any leading SP characters from input_string. </del> <ins> Discard any leading OWS characters from input_string. </ins> If input_string is empty, there is a trailing comma; fail parsing.
software update images.  Doing so improves responsiveness of other connections at the cost of delaying the delivery of updates. <del> Also, a client MAY use the priority values for making local scheduling choices for the requests it initiates. 8. </del> <ins> 9. </ins> Contrary to the prioritization scheme of HTTP/2 that uses a hop-by- hop frame, the Priority header field is defined as end-to-end.
state.  This state can be limited by adopting the guidance about concurrency limits described above.  Extensible priorities is subject to a similar consideration because PRIORITY_UPDATE frames may arrive <del> before the request that they reference.  A server could retain the information in order to apply the most up-to-date signal to the request.  However, HTTP/3 implementations might have practical </del> <ins> before the request that they reference.  A server is required to store the information in order to apply the most up-to-date signal to the request.  However, HTTP/3 implementations might have practical </ins> barriers to determining reasonable stream concurrency limits depending on the information that is available to them from the QUIC transport layer.  TODO: so what can we suggest?
2.1. <del> An HTTP header field value is identified by its header field name. While HTTP header field names are case-insensitive, implementations SHOULD use lowercased field names (e.g., "content-type", "date", "etag") when using them as content identifiers. </del> <ins> An HTTP header field is identified by its header field name.  While HTTP header field names are case-insensitive, implementations MUST use lowercased field names (e.g., "content-type", "date", "etag") when using them as content identifiers. </ins> An HTTP header field value is canonicalized as follows:
The signer creates an ordered list of content identifiers representing the message content and signature metadata to be covered by the signature, and assigns this list as the signature's <del> Covered Content.  Each identifier MUST be one of those defined in Section 2.  This list MUST NOT be empty, as this would result in creating a signature over the empty string.  If the signature's Algorithm name does not start with rsa, hmac, or ecdsa, signers SHOULD include (created) and (request-target) in the list.  If the signature's Algorithm starts with rsa, hmac, or ecdsa, signers SHOULD include date and (request-target) in the list.  Further guidance on what to include in this list and in what order is out of scope for this document.  However, the list order is significant and once established for a given signature it MUST be preserved for that signature. </del> <ins> Covered Content. Each identifier MUST be one of those defined in Section 2. This list MUST NOT be empty, as this would result in creating a signature over the empty string. If the signature's Algorithm name does not start with rsa, hmac, or ecdsa, signers SHOULD include (created) and (request- target) in the list. If the signature's Algorithm starts with rsa, hmac, or ecdsa, signers SHOULD include date and (request-target) in the list. Further guidance on what to include in this list and in what order is out of scope for this document.  However, the list order is significant and once established for a given signature it MUST be preserved for that signature. </ins> For example, given the following HTTP message:
2.3.21. <del> Name: tls_handshake_error </del> <ins> Name: tls_protocol_error </ins> <del> Description: The intermediary encountered an error during TLS handshake with the next hop. Extra Parameters: </del> <ins> Description: The intermediary encountered a TLS error when communicating with the next hop, either during handshake or afterwards. </ins> <del> alert_message: a sf-token containing the applicable description string from the TLS Alerts registry. </del> <ins> Extra Parameters: None. </ins> Recommended HTTP status code: 502 2.3.22. <del> Name: tls_untrusted_peer_certificate </del> <ins> Name: tls_certificate_error </ins> <del> Description: The intermediary received an untrusted peer certificate during TLS handshake with the next hop. </del> <ins> Description: The intermediary encountered an error when verifying the certificate presented by the next hop. </ins> Extra Parameters: None.
2.3.23. <del> Name: tls_expired_peer_certificate Description: The intermediary received an expired peer certificate during TLS handshake with the next hop. Extra Parameters: None. Recommended HTTP status code: 502 2.3.24. Name: tls_unexpected_peer_certificate Description: The intermediary received an unexpected peer certificate (e.g., SPKI doesn't match) during the TLS handshake with the next hop. Extra Parameters: identity: a sf-string containing a comma-separated list of Subject Alternative Names from the certificate received from the next hop. sha256: a sf-string containing the hex-encoded SHA-256 of the certificate received from the next hop. spki: a sf-string containing the base64-encoded SHA-256 of the Subject Public Key Info (SPKI) from the certificate received from the next hop. Recommended HTTP status code: 502 2.3.25. Name: tls_missing_proxy_certificate Description: The next hop requested a client certificate from the intermediary during TLS handshake, but it wasn't configured with one. </del> <ins> Name: tls_alert_received </ins> <del> Extra Parameters: None. Recommended HTTP status code: 500 2.3.26. Name: tls_rejected_proxy_certificate Description: The next hop rejected the client certificate provided by the intermediary during TLS handshake. Extra Parameters: None. Recommended HTTP status code: 500 2.3.27. Name: tls_error Description: The intermediary encountered a TLS error when communicating with the next hop. </del> <ins> Description: The intermediary received a TLS alert from the next hop. </ins> Extra Parameters:
The representation digest is an integrity mechanism for HTTP resources which uses a checksum that is calculated independently of <del> the payload body and message body.  It uses the representation data (see Section 7.1 of SEMANTICS), that can be fully or partially contained in the message body, or not contained at all: </del> <ins> the payload body (see Section 7.3.3 of SEMANTICS).  It uses the representation data (see Section 7.1 of SEMANTICS), that can be fully or partially contained in the payload body, or not contained at all: </ins> This takes into account the effect of the HTTP semantics on the messages; for example the payload body can be affected by Range <del> Requests or methods such as HEAD, while the message body is dependent on transfer codings and other transformations: resource- </del> <ins> Requests or methods such as HEAD, while the way the payload body is transferred "on the wire" is dependent on other transformations (eg. transfer codings for HTTP/1.1 see 6.1 of HTTP11): resource- </ins> representation contains several examples to help illustrate those effects.
after validating the Digest. If received in trailers, Digest MUST NOT be discarded; instead it MAY <del> be merged in the header section (See Section 7.1.2 of !MESSAGING=I- D.ietf-httpbis -messaging). </del> <ins> be merged in the header section (See Section 5.6.2 of SEMANTICS). </ins> Not every digest-algorithm is suitable for trailers, as they may require to pre-process the whole payload before sending a message
5. <del> Digest algorithm values are used to indicate a specific digest computation.  For some algorithms, one or more parameters can be supplied. </del> <ins> Digest-algorithm values are used to indicate a specific digest computation.  For some digest-algorithms, one or more parameters can be supplied. </ins> The BNF for "parameter" is defined in Section 5.4.1.4 of SEMANTICS. All digest-algorithm values are case-insensitive.
digest-algorithm values.  The registry contains the tokens listed below. <del> Some algorithms, although registered, have since been found vulnerable: the "MD5" algorithm MUST NOT be used due to collision attacks CMU-836068 and the "SHA" algorithm MUST NOT be used due to collision attacks IACR-2020-014. </del> <ins> Some digest-algorithms, although registered, rely on vulnerable algorithms: the "MD5" digest-algorithm MUST NOT be used due to collision attacks CMU-836068 and the "SHA" digest-algorithm MUST NOT be used due to collision attacks IACR-2020-014. </ins>
The status of "MD5" has been updated to "deprecated", and its description states that this algorithm MUST NOT be used. <del> The status of "SHA" has been updated to "obsoleted", and its description states that this algorithm is NOT RECOMMENDED. </del> <ins> The status of "SHA" has been updated to "deprecated", and its description states that this algorithm MUST NOT be used. </ins> The status for "CRC32c" has been updated to "standard".
transmission of software update files that would have the background urgency being associated.  However, in the worst case, the asymmetry between the precedence declared by multiple clients might cause <del> responses going to one end client to be delayed totally after those </del> <ins> responses going to one user agent to be delayed totally after those </ins> going to another. <del> In order to mitigate this fairness problem, when a server responds to a request that is known to have come through an intermediary, the server SHOULD prioritize the response as if it was assigned the priority of "u=1, i" (i.e. round-robin) regardless of the value of the Priority header field being transmitted, unless the server knows the intermediary is not coalescing requests from multiple clients. </del> <ins> In order to mitigate this fairness problem, a server could use knowledge about the intermediary as another signal in its prioritization decisions.  For instance, if a server knows the intermediary is coalescing requests, then it could serve the responses in round-robin manner.  This can work if the constrained resource is network capacity between the intermediary and the user agent, as the intermediary buffers responses and forwards the chunks based on the prioritization scheme it implements. </ins> A server can determine if a request came from an intermediary through configuration, or by consulting if that request contains one of the
Via (RFC7230, Section 5.7.1) <del> Responding to requests coming through an intermediary in a round- robin manner works well when the network bottleneck exists between the intermediary and the end client, as the intermediary would be buffering the responses and then be forwarding the chunks of those buffered responses based on the prioritization scheme it implements. A sophisticated server MAY use a weighted round-robin reflecting the urgencies expressed in the requests, so that less urgent responses would receive less bandwidth in case the bottleneck exists between the server and the intermediary. </del> 8.2. It is common for CDN infrastructure to support different HTTP
A PRIORITY_UPDATE frame communicates a complete set of all parameters in the Priority Field Value field.  Omitting a parameter is a signal to use the parameter's default value.  Failure to parse the Priority <del> Field Value MUST be treated as a connection error of type FRAME_ENCODING_ERROR. </del> <ins> Field Value MUST be treated as a connection error.  In HTTP/2 the error is of type PROTOCOL_ERROR; in HTTP/3 the error is of type H3_FRAME_ERROR. </ins> A client MAY send a PRIORITY_UPDATE frame before the stream that it references is open.  Furthermore, HTTP/3 offers no guaranteed
"Digest" may expose information details of encrypted payload when the checksum is computed on the unencrypted data.  An example of that is <del> the use of the "id-sha-256" digest-algorithm in conjuction with the </del> <ins> the use of the "id-sha-256" digest-algorithm in conjunction with the </ins> encrypted content-coding RFC8188. <ins> The representation-data-digest of an encrypted payload can change between different messages depending on the encryption algorithm used; in those cases its value could not be used to provide a proof of integrity "at rest" unless the whole (e.g. encoded) payload body is persisted. </ins> 11.9. ...
However, there are cases where relying on this alone is insufficient. An HTTP-level integrity mechanism that operates independent of transfer can be used to detect programming errors and/or corruption <del> of data at rest, be used across multiple hops in order to provide end-to-end integrity guarantees, aid fault diagnosis across hops and system boundaries, and can be used to validate integrity when reconstructing a resource fetched using different HTTP connections. </del> <ins> of data in flight or at rest, be used across multiple hops in order to provide end-to-end integrity guarantees, aid fault diagnosis across hops and system boundaries, and can be used to validate integrity when reconstructing a resource fetched using different HTTP connections. </ins> This document defines a mechanism that acts on HTTP representation- data.  It can be combined with other mechanisms that protect