jiebi/CodeConvo huggingface dataset:
both "http" and "https" URIs might use the same connection, because HTTP/2 permits requests for multiple origins on the same connection. <del> Because of the risk of server confusion about individual requests' schemes (see confuse), clients MUST NOT send "http" requests on a connection that has previously been used for "https" requests, unless the http-opportunistic origin object well-known fetched over that connection has a "mixed-scheme" member whose value is "true". </del> <ins> Because of the potential for server confusion about the scheme of requests (see confuse), clients MUST NOT send "http" requests on a connection prior to successfully retrieving a valid http- opportunistic resource that contains the origin (see well-known). The primary purpose of this check is to provide a client with some assurance that a server understands this specification and has taken steps to avoid being confused about request scheme. </ins> 2.3.
That response has the media type "application/json", and That response's payload, when parsed as JSON RFC7159, contains an <del> object as the root, and The root object contains a member whose name is a case-insensitive character-for-character match for the origin in question, serialised into Unicode as per Section 6.1 of RFC6454, and whose value is an object (hereafter, the "origin object"), The origin object has a "lifetime" member, whose value is a number indicating the number of seconds which the origin object is valid for (hereafter, the "origin object lifetime"), and </del> <ins> array as the root, and </ins> <del> The origin object lifetime is greater than the "current_age" (as per RFC7234, Section 4.2.3). </del> <ins> The array contains a string that is a case-insensitive character- for-character match for the origin in question, serialised into Unicode as per Section 6.1 of RFC6454. </ins> <del> Note that origin object lifetime might differ from the freshness lifetime of the response. </del> <ins> A client MAY treat an "http-opportunistic" resource as invalid if the contains values that are not strings. </ins> 3.
The ORIGIN Extension in HTTP/3 <del> draft-ietf-httpbis-origin-h3-latest </del> Abstract <del> The ORIGIN frame for HTTP/2 is equally applicable to HTTP/3, but </del> <ins> The ORIGIN frame for HTTP/2 is equally applicable to HTTP/3, but it </ins> needs to be separately registered.  This document describes the ORIGIN frame for HTTP/3. 1. <del> Existing RFCs define extensions to HTTP/2 HTTP2 which remain useful in HTTP/3.  HTTP3 describes the required updates for HTTP/2 frames to be used with HTTP/3. </del> <ins> Existing RFCs define extensions to HTTP/2 RFC9113 that remain useful in HTTP/3.  RFC9114 describes the required updates for HTTP/2 frames to be used with HTTP/3. </ins> ORIGIN defines the HTTP/2 ORIGIN frame, which indicates what origins are available on a given connection.  It defines a single HTTP/2
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <del> Frame diagrams in this document use the format defined in QUIC- </del> <ins> The frame diagram in this document uses the format defined in QUIC- </ins> TRANSPORT to illustrate the order and size of fields. 2. <del> The ORIGIN HTTP/3 frame allows a server to indicate what origin(s) (RFC6454) the server would like the client to consider as members of the Origin Set (ORIGIN) for the connection within which it occurs. </del> <ins> The ORIGIN HTTP/3 frame allows a server to indicate what origin or origins RFC6454 the server would like the client to consider as one or more members of the Origin Set (ORIGIN) for the connection within which it occurs. </ins> The semantics of the frame payload are identical to those of the <del> HTTP/2 frame defined in ORIGIN.  Where HTTP/2 reserves Stream 0 for </del> <ins> HTTP/2 frame defined in ORIGIN.  Where HTTP/2 reserves stream 0 for </ins> frames related to the state of the connection, HTTP/3 defines a pair of unidirectional streams called "control streams" for this purpose. <del> Where ORIGIN indicates that the ORIGIN frame should be sent on Stream 0, this should be interpreted to mean the HTTP/3 control stream.  The ORIGIN frame is sent from servers to clients on the server's control stream. </del> <ins> Where ORIGIN indicates that the ORIGIN frame is sent on stream 0, this should be interpreted to mean the HTTP/3 control stream: that is, the ORIGIN frame is sent from servers to clients on the server's control stream. </ins> HTTP/3 does not define a Flags field in the generic frame layout.  As no flags have been defined for the ORIGIN frame, this specification
2.1. <del> The ORIGIN frame has a nearly identical layout to that used in HTTP/2, restated here for clarity.  The ORIGIN frame type is 0xc (decimal 12) as in HTTP/2.  The payload contains zero or more instances of the Origin-Entry field. </del> <ins> The ORIGIN frame has a layout that is nearly identical to the layout used in HTTP/2; the information is restated here for clarity.  The ORIGIN frame type is 0x0c (decimal 12), as in HTTP/2.  The payload contains zero or more instances of the Origin-Entry field. </ins> An Origin-Entry is a length-delimited string.  Specifically, it contains two fields:
3. This document introduces no new security considerations beyond those <del> discussed in ORIGIN and HTTP3. </del> <ins> discussed in ORIGIN and RFC9114. </ins> 4. <del> This document registers a frame type in the "HTTP/3 Frame Type" registry (HTTP3). This allocation lists a change controller of the IETF and a contact of the HTTP working group (ietf-http-wg@w3.org). </del> <ins> This document registers a frame type in the "HTTP/3 Frame Types" registry defined by RFC9114, located at <https://www.iana.org/assignments/http3-parameters/>. </ins>
The "next-hop-aliases" parameter's value is a String STRUCTURED- FIELDS that contains one or more DNS names in a comma-separated list. <del> The items in the list include all alias names an canonical names </del> <ins> The items in the list include all alias names and canonical names </ins> received in CNAME records DNS during the course of resolving the next hop's hostname using DNS, not including the original requested hostname itself.  The names SHOULD appear in the order in which they
fields, from certain kinds of corruption. Integrity fields are not intended to be a general protection against <del> malicious tampering with HTTP messages.  This can be achieved by combining it with other approaches such as transport-layer security or digital signatures (for example, HTTP Message Signatures SIGNATURES). </del> <ins> malicious tampering with HTTP messages.  In the absence of additional security mechanisms, an on-path, malicious actor can remove or recalculate and substitute a digest value.  This attack can be mitigated by combining mechanisms described in this document with other approaches such as transport-layer security or digital signatures (for example, HTTP Message Signatures SIGNATURES). </ins> 6.2.
content coding defined in RFC8188. Since it is possible for there to be variation within content coding, <del> the checksum conveyed by the integrity field cannot be used to provide a proof of integrity "at rest" unless the whole (e.g., encoded) content is persisted. </del> <ins> the checksum conveyed by the integrity fields cannot be used to provide a proof of integrity "at rest" unless the whole content is persisted. </ins> 6.6.
"insecure" - for insecure algorithms, <del> "reserved" - for algorithms that use a reserved token value that cannot be expressed in Structured Fields </del> Description: a short description of the algorithm Reference(s): pointer(s) to the primary document(s) defining the <del> technical details of the algorithm, and optionally the key </del> <ins> Algorithm Key and technical details of the algorithm </ins> When reviewing registration requests, the designated expert(s) should pay attention to the requested status.  The status value should
capabilities.  Such an approach could support transitions away from weaker algorithms (see sec-agility). <del> A recipient MAY ignore any or all digests.  This allows the recipient to choose which hashing algorithm(s) to use for validation instead of verifying every digest. </del> <ins> A recipient MAY ignore any or all digests.  Application-specific behavior or local policy MAY set additional constraints on the processing and validation practices of the conveyed digests.  For example, validation of a subset of received digests is one approach to protection against resource exhaustion; see resource-exhaustion. </ins> A sender MAY send a digest without knowing whether the recipient supports a given hashing algorithm, or even knowing that the
unsupported-algorithm.  It is not a protocol error if preferences are ignored.  Applications that use Integrity fields and Integrity preferences can define expectations or constraints that operate in <del> addition to this specification.  How to deal with ignored preferences is a scenario that should be considered. </del> <ins> addition to this specification.  Ignored preferences are an application-specific concern. </ins> "Want-Content-Digest" and "Want-Repr-Digest" are of type "Dictionary" where each:
This indicates that proxy.example.net, which used the IP address "2001:db8::1" as the next hop for this request, encountered the names <del> "tracker.example.com" and "service1.example-cdn.com" in the DNS </del> <ins> "tracker.example.com" and "service1.example.com" in the DNS </ins> resolution chain.  Note that while this example includes both the "next-hop" and "next-hop-aliases" parameters, "next-hop-aliases" can be included without including "next-hop".
Unreserved Characters (RFC3986, Section 2.3) MUST be percent-encoded as defined in RFC3986, Section 2.1. <del> For example, consider the DNS name "name,with,commas.example.com". This name would be encoded within a "next-hop-aliases" parameter as </del> <ins> For example, consider the DNS name "comma,name.example.com".  This name would be encoded within a "next-hop-aliases" parameter as </ins> follows: It is also possible for a DNS name to include a period character
ephemeral keys to acquire access to geography- or capability-specific resources, as issued by an entity whose user base is larger than the available resources can support (by having that entity metering the <del> availability of keys temporally or geographically).  Unprompted Authentication is also useful for cases where a service provider wants to distribute user-provisioning information for its resources without exposing the provisioning location to non-users. </del> <ins> availability of keys temporally or geographically).  The Signature HTTP authentication scheme is also useful for cases where a service provider wants to distribute user-provisioning information for its resources without exposing the provisioning location to non-users. </ins> There are scenarios where servers may want to expose the fact that authentication is required for access to specific resources.  This is
response that they would have used for non-existent resources.  For example, this can mean using HTTP status code 404 (Not Found) instead of 401 (Unauthorized).  Such authentication failures can be caused <del> for example by: * absence of the Unprompted-Authentication field * failure to parse the Unprompted-Authentication field * use of Unprompted Authentication with an unknown key ID * failure to validate the signature or MAC. </del> <ins> for example by: * absence of the Authorization field * failure to parse the Authorization field * use of the Signature authentication scheme with an unknown key ID * failure to validate the signature. </ins> Such servers MUST also ensure that the timing of their request handling does not leak any information.  This can be accomplished by delaying responses to all non-existent resources such that the timing of the authentication verification is not observable. <del> 7. </del> <ins> 6. </ins> <del> Since the Signature and HMAC HTTP Authentication Schemes leverage TLS keying material exporters, their output cannot be transparently forwarded by HTTP intermediaries.  HTTP intermediaries that support this specification have two options: </del> <ins> Since the Signature HTTP authentication scheme leverages TLS keying material exporters, its output cannot be transparently forwarded by HTTP intermediaries.  HTTP intermediaries that support this specification have two options: </ins> The intermediary can validate the authentication received from the client, then inform the upstream HTTP server of the presence of
3. <del> The user agent leverages a TLS keying material exporter KEY-EXPORT with the label "EXPORTER-HTTP-Signature-Authentication" to generate a 32-byte symmetric key.  That symmetric key is then used as nonce which can be signed using the client's chosen asymmetric private key. The resulting signature is then transmitted to the server using the Authorization field. </del> <ins> The user agent computes the authentication proof using a TLS keying material exporter KEY-EXPORT with the following parameters: the label is set to "EXPORTER-HTTP-Signature-Authentication" the context is set to the structure described in the exporter output length is set to 32 bytes (see output) 3.1. The TLS key exporter context is described in fig-context, using the notation from QUIC: The key exporter context contains the following fields: The Signature Algorithm and Port fields are encoded as unsigned 16-bit integers in network byte order.  The Key ID, Scheme, Host, and Real fields are length prefixed strings; they are preceded by a Length field that represents their length in bytes.  These length fields are encoded using the variable-length integer encoding from QUIC and MUST be encoded in the minimum number of bytes necessary. 3.2. The output of the exporter is a 32-byte symmetric key.  That symmetric key is then used as nonce which can be signed using the client's chosen asymmetric private key.  The resulting signature is then transmitted to the server using the Authorization field. </ins> 4. <del> This specification defines the following authentication parameters: </del> <ins> This specification defines the following authentication parameters. These parameters use structured fields (STRUCTURED-FIELDS) in their definition, even though the Authorization field itself does not use structured fields. </ins> 4.1.
NOT be reused in other protocols.  Doing so can undermine the security guarantees of the authentication. <del> Origins offering this scheme are able to link requests that use the same key.  However, requests are not linkable across origins if the keys used are specific to the individual origins using this scheme. </del> <ins> Origins offering this scheme can link requests that use the same key. However, requests are not linkable across origins if the keys used are specific to the individual origins using this scheme. </ins> 8.
3.2. <del> The output of the exporter is a 32-byte symmetric key.  That symmetric key is then used as nonce which can be signed using the client's chosen asymmetric private key.  The resulting signature is then transmitted to the server using the Authorization field. </del> <ins> The key exporter output is 48 bytes long.  Of those, the first 32 bytes are input to the signature and the next 16 bytes are sent alongside the signature.  This allows the recipient to confirm that the exporter produces the right values.  This is described in fig- output: The key exporter context contains the following fields: </ins> 4.
<<https://www.iana.org/assignments/tls-parameters/tls- parameters.xhtml#tls-signaturescheme>>. <ins> 4.4. The REQUIRED "v" (verification) parameter is a byte sequence that specifies the verification that the user agent provides to attest to possessing the key exporter output.  This avoids issues with signature schemes where certain keys can generate signatures that are valid for multiple inputs (see SEEMS-LEGIT). </ins> For example, the key ID "basement" authenticating using Ed25519 ED25519 could produce the following header field (lines are folded to fit):
of 401 (Unauthorized).  Such authentication failures can be caused for example by: * absence of the Authorization field * failure to parse the Authorization field * use of the Signature authentication <del> scheme with an unknown key ID * failure to validate the signature. </del> <ins> scheme with an unknown key ID * failure to validate the verification parameter * failure to validate the signature. </ins> Such servers MUST also ensure that the timing of their request handling does not leak any information.  This can be accomplished by
client, then inform the upstream HTTP server of the presence of valid authentication. <del> The intermediary can export the nonce (see compute-proof}), and forward it to the upstream HTTP server, then the upstream server performs the validation. </del> <ins> The intermediary can export the nonce and verification (see compute-proof}), and forward it to the upstream HTTP server, then the upstream server performs the validation. </ins> The mechanism for the intermediary to communicate this information to the upstream HTTP server is out of scope for this document.
The key exporter context contains the following fields: <ins> 3.3. Once the nonce has been extracted from the key exporter output (see output), it is prefixed with static data before being signed to mitigate issues caused by key reuse.  The signature is computed over the concatenation of: A string that consists of octet 32 (0x20) repeated 64 times The context string "HTTP Signature Authentication" A single 0 byte which serves as a separator The nonce extracted from the key exporter output (see output) For example, if the nonce has all its 32 bytes set to 01, the content covered by the signature (in hexadecimal format) would be: This constructions mirrors that of the TLS 1.3 CertificateVerify message defined in TLS. The resulting signature is then transmitted to the server using the "p" Parameter (see parameter-p). </ins> 4. This specification defines the following authentication parameters.
Each algorithm has a status field, which is intended to provide an aid to implementation selection. <del> Algorithms with a status value of "standard" are suitable for many </del> <ins> Algorithms with a status value of "Active" are suitable for many </ins> purposes and it is RECOMMENDED that applications use these algorithms.  These can be used in adversarial situations where hash functions might need to provide resistance to collision, first- preimage and second-preimage attacks.  For adversarial situations, <del> selecting which of the "standard" algorithms are acceptable will depend on the level of protection the circumstances demand.  More </del> <ins> selecting which of the "Active" algorithms are acceptable will depend on the level of protection the circumstances demand.  More </ins> considerations are presented in sec-agility. <del> Algorithms with a status value of "insecure" either provide none of </del> <ins> Algorithms with a status value of "Deprecated" either provide none of </ins> these properties, or are known to be weak (see NO-MD5 and NO-SHA). These algorithms MAY be used to preserve integrity against corruption, but MUST NOT be used in a potentially adversarial
Status: the status of the algorithm.  The options are: <del> "standard" - for standardized algorithms without known problems, </del> <ins> "Active" - for algorithms without known problems, </ins> <del> "provisional" - for non-standard or unproven algorithms, </del> <ins> "Provisional" - for unproven algorithms, </ins> <del> "insecure" - for insecure algorithms, </del> <ins> "Deprecated" - for deprecated or insecure algorithms, </ins> Description: a short description of the algorithm
pay attention to the requested status.  The status value should reflect standardization status and the broad opinion of relevant interest groups such as the IETF or security-related SDOs.  The <del> "standard" status is not suitable for an algorithm that is known to be weak, broken, or experimental.  If a registration request attempts to register such an algorithm as "standard", the designated expert(s) should suggest an alternative status of "insecure" or "provisional". </del> <ins> "Active" status is not suitable for an algorithm that is known to be weak, broken, or experimental.  If a registration request attempts to register such an algorithm as "Active", the designated expert(s) should suggest an alternative status of "Deprecated" or "Provisional". </ins> When reviewing registration requests, the designated expert(s) cannot <del> use a status of "insecure" or "provisional" as grounds for rejection. </del> <ins> use a status of "Deprecated" or "Provisional" as grounds for rejection. </ins> Requests to update or change the fields in an existing registration are permitted.  For example, this could allow for the transition of <del> an algorithm status from "standard" to "insecure" as the security </del> <ins> an algorithm status from "Active" to "Deprecated" as the security </ins> environment evolves. 6.
Given a string of Unicode characters as input_string, return an ASCII string suitable for use in an HTTP field value. <ins> If input_string is not a string of Unicode characters, fail parsing. </ins> Let byte_array be the result of applying UTF-8 encoding UTF8 to <del> input_string.  If there is an error in doing so, fail parsing. </del> <ins> input_string. </ins> Let encoded_string be an empty string. For each byte in byte_array: <del> If byte is %x25 ("%"), append "%25" to encoded_string. </del> <ins> If byte is %x25 ("%"), %x22 (DQUOTE), or in the ranges %x00-1f or %x7f-ff: </ins> <del> If byte is in the ranges %x00-1f or %x7f-ff, apply the percent- encoding defined in Section 2.1 of URI to byte and append the result to encoded_string. </del> <ins> Append "%" to encoded_string. Let encoded_byte be the result of applying base16 encoding (Section 8 of RFC4648) to byte. Append encoded_byte to encoded_string. </ins> Otherwise, decode byte as an ASCII character and append the result to encoded_string. <del> Let formatted_string be the result of running Serialising a String (ser-string) with encoded_string. </del> <ins> Let output be a string containing "%" followed by DQUOTE. </ins> <del> Return the character "%" followed by formatted_string. </del> <ins> Append encoded_string to output. Append DQUOTE to output. Return output. </ins> 4.2.