jiebi/CodeConvo huggingface dataset:
the following fields should usually not be included in the signature unless the application specifically requires it: <ins> 7.21. The create-sig-input uses the value of an HTTP field as its component value.  In the common case, this amounts to taking the actual bytes of the field value as the component value for both the signer and verifier.  However, some field values allow for transformation of the values in semantically equivalent ways that alter the bytes used in the value itself.  For example, a field definition can declare some or all of its value to be case-insensitive, or to have special handling of internal whitespace characters.  Other fields have expected transformations from intermediaries, such as the removal of comments in the "Via" header field.  In such cases, a verifier could be tripped up by using the equivalent transformed field value, which would differ from the byte value used by the signer.  The verifier would have have a difficult time finding this class of errors since the value of the field is still acceptable for the application, but the actual bytes required by the signature base would not match. When processing such fields, the signer and verifier have to agree how to handle such transformations, if at all.  One option is to not sign problematic fields, but care must be taken to ensure that there is still security-coverage for the application.  Another option is to define an application-specific canonicalization value for the field before it is added to the HTTP message, such as to always remove internal comments before signing, or to always transform values to lowercase.  Since these transformations are applied prior to the field being used as input to the signature base generation algorithm, the signature base will still simply contain the byte value of the field as it appears within the message.  If the transformations were to be applied after the value is extracted from the message but before it is added to the signature base, different attack surfaces such as value substitution attacks could be launched against the application.  All application-specific additional rules are outside the scope of this specification, and by their very nature these transformations would harm interoperability of the implementation outside of this specific application.  It is recommended that applications avoid the use of such additional rules wherever possible. </ins> 8. 8.1.
content with a length prefix, and a trailer section with a length prefix. <ins> For a known-length encoding, the length prefix on field sections and content is a variable-length encoding of an integer.  This integer is the number of bytes in the field section or content. </ins> Response messages that contain informational status codes result in a different structure; see informational.  Note that while the Known- Length Informational Response field is shown in format-known-length,
value, any number of non-zero-length chunks of binary content, a zero value, and a trailer section that is terminated by a zero value. <ins> The indeterminate-length encoding only uses length prefixes for content blocks.  Multiple length-prefixed portions of content can be included, each prefixed by a non-zero Chunk Length integer describing the number of bytes in the block.  The Chunk Length is encoded as a variable-length integer. Each Field Line in an Indeterminate-Length Field Section starts with a Name Length field.  An Indeterminate-Length Field Section ends with a Content Terminator field.  The zero value of the Content Terminator distinguishes it from the Name Length field, which cannot contain a value of 0. </ins> Response messages that contain informational status codes result in a different structure; see informational.  Note that while the Indeterminate-Length Informational Response field is shown in format-
control data rather than using pseudo-fields.  Messages are invalid (invalid) if they contain fields named ":method", ":scheme", ":authority", ":path", or ":status".  Other pseudo-fields that are <del> defined by protocol extensions MAY be included.  Field lines containing pseudo-fields MUST precede other field lines.  A message that contains a pseudo-field after any other field is invalid; see invalid. </del> <ins> defined by protocol extensions MAY be included; pseudo-fields cannot be included in trailers (see H2).  Field lines containing pseudo- fields MUST precede other field lines.  A message that contains a pseudo-field after any other field is invalid; see invalid. </ins> Note that while some messages - CONNECT or upgrade requests in particular - can be represented using this format, doing so serves no
2.2.9. If a request target URI uses HTML form parameters in the query string <del> as defined in HTMLURL, the "@query-params" component identifier allows addressing of individual query parameters.  The query parameters MUST be parsed according to HTMLURL, resulting in a list of ("nameString", "valueString") tuples.  The REQUIRED "name" parameter of each input identifier contains the "nameString" of a single query parameter as an "sf-string" value.  Several different named query parameters MAY be included in the covered components. Single named parameters MAY occur in any order in the covered components. </del> <ins> as defined in HTMLURL, the "@query-param" component identifier allows addressing of individual query parameters.  The query parameters MUST be parsed according to HTMLURL, resulting in a list of ("nameString", "valueString") tuples.  The REQUIRED "name" parameter of each input identifier contains the "nameString" of a single query parameter as an "sf-string" value.  Several different named query parameters MAY be included in the covered components.  Single named parameters MAY occur in any order in the covered components. </ins> The component value of a single named parameter is the the "valueString" of the named query parameter defined by HTMLURL, which
A consequence of this record structure is that range requests RFC7233 and random access to encrypted payload bodies are possible at the granularity of the record size.  However, without data from adjacent <del> ranges, partial records cannot be used.  Thus, it is best if records start and end on multiples of the record size, plus the 16 octet authentication tag size. </del> <ins> ranges, partial records cannot be used.  Thus, it is best if range requests start and end on multiples of the record size, plus the 16 octet authentication tag size. </ins> 3.
1. "Bootstrapping WebSockets with HTTP/2" RFC8441 defines an extension <del> to HTTP/2 HTTP2 which is also useful in HTTP/3 HTTP3.  This extension makes use of an HTTP/2 setting.  HTTP3 gives some guidance on what changes (if any) are appropriate when porting settings from HTTP/2 to HTTP/3. </del> <ins> to HTTP/2 HTTP/2 which is also useful in HTTP/3 HTTP/3.  This extension makes use of an HTTP/2 setting.  HTTP/3 gives some guidance on what changes (if any) are appropriate when porting settings from HTTP/2 to HTTP/3. </ins> 2.
server to allow the client to use Extended CONNECT. The semantics of the pseudo-header fields and setting are identical <del> to those in HTTP/2 as defined RFC8441.  HTTP3 requires that HTTP/3 </del> <ins> to those in HTTP/2 as defined RFC8441.  HTTP/3 requires that HTTP/3 </ins> settings be registered separately for HTTP/3.  The SETTINGS_ENABLE_CONNECT_PROTOCOL value is 0x08 (decimal 8), as in HTTP/2.
The HTTP/3 stream closure is also analogous to the TCP connection closure of RFC6455.  Orderly TCP-level closures are represented as a <del> FIN bit on the stream (HTTP3).  RST exceptions are represented with a stream error (HTTP3) of type H3_REQUEST_CANCELLED (HTTP3). </del> <ins> FIN bit on the stream (HTTP/3).  RST exceptions are represented with a stream error (HTTP/3) of type H3_REQUEST_CANCELLED (HTTP/3). </ins> 4.
1. "Bootstrapping WebSockets with HTTP/2" RFC8441 defines an extension <del> to HTTP/2 HTTP/2 that is also useful in HTTP/3 HTTP/3.  This extension makes use of an HTTP/2 setting.  HTTP/3 gives some guidance on what changes (if any) are appropriate when porting settings from HTTP/2 to HTTP/3. </del> <ins> to HTTP/2 HTTP2 that is also useful in HTTP/3 HTTP3.  This extension makes use of an HTTP/2 setting.  HTTP3 gives some guidance on what changes (if any) are appropriate when porting settings from HTTP/2 to HTTP/3. </ins> 2.
server to allow the client to use Extended CONNECT. The semantics of the pseudo-header fields and setting are identical <del> to those in HTTP/2 as defined in RFC8441.  HTTP/3 requires that HTTP/3 settings be registered separately for HTTP/3.  The </del> <ins> to those in HTTP/2 as defined in RFC8441.  HTTP3 requires that HTTP/3 settings be registered separately for HTTP/3.  The </ins> SETTINGS_ENABLE_CONNECT_PROTOCOL value is 0x08 (decimal 8), as in HTTP/2.
The HTTP/3 stream closure is also analogous to the TCP connection closure of RFC6455.  Orderly TCP-level closures are represented as a <del> FIN bit on the stream (HTTP/3).  RST exceptions are represented with a stream error (HTTP/3) of type H3_REQUEST_CANCELLED (HTTP/3). </del> <ins> FIN bit on the stream (HTTP3).  RST exceptions are represented with a stream error (HTTP3) of type H3_REQUEST_CANCELLED (HTTP3). </ins> 4.
Some of these features are also absent in HTTP/2 and HTTP/3. <del> Unlike HTTP/2 and HTTP/3, this format uses a a fixed format for control data rather than using pseudo-fields.  Messages are invalid (invalid) if they contain fields named ":method", ":scheme", ":authority", ":path", or ":status".  Other pseudo-fields that are defined by protocol extensions MAY be included; pseudo-fields cannot be included in trailers (see H2).  Field lines containing pseudo- fields MUST precede other field lines.  A message that contains a pseudo-field after any other field is invalid; see invalid. </del> <ins> Unlike HTTP/2 and HTTP/3, this format uses a fixed format for control data rather than using pseudo-fields.  Messages are invalid (invalid) if they contain fields named ":method", ":scheme", ":authority", ":path", or ":status".  Other pseudo-fields that are defined by protocol extensions MAY be included; pseudo-fields cannot be included in trailers (see H2).  Field lines containing pseudo-fields MUST precede other field lines.  A message that contains a pseudo-field after any other field is invalid; see invalid. </ins> Note that while some messages - CONNECT or upgrade requests in particular - can be represented using this format, doing so serves no
For more advanced use-cases, the "Repr-Digest" request and response header and trailer field (representation-digest) is defined.  It contains a digest value computed by applying a hashing algorithm to <del> "selected representation data" (SEMANTICS).  Basing "Repr-Digest" on </del> <ins> selected representation data (SEMANTICS).  Basing "Repr-Digest" on </ins> the selected representation makes it straightforward to apply it to use-cases where the transferred data requires some sort of manipulation to be considered a representation or conveys a partial
representation concepts, several examples are provided in resource- representation. <del> When a message has no "representation data" it is still possible to assert that no "representation data" was sent by computing the digest </del> <ins> When a message has no representation data it is still possible to assert that no representation data was sent by computing the digest </ins> on an empty string (see usage-in-signatures). "Repr-Digest" is a "Dictionary" (see STRUCTURED-FIELDS) where each:
6.2. <del> Integrity fields can help detect "representation data" or content </del> <ins> Integrity fields can help detect representation data or content </ins> modification due to implementation errors, undesired "transforming proxies" (see SEMANTICS) or other actions as the data passes across multiple hops or system boundaries.  Even a simple mechanism for end- <del> to-end "representation data" integrity is valuable because a user agent can validate that resource retrieval succeeded before handing off to a HTML parser, video player etc. for parsing. </del> <ins> to-end representation data integrity is valuable because a user agent can validate that resource retrieval succeeded before handing off to a HTML parser, video player etc. for parsing. </ins> Note that using these mechanisms alone does not provide end-to-end integrity of HTTP messages over multiple hops, since metadata could
application data sent on such a connection after receipt and verification of the client certificate is also mutually-authenticated and thus suitable for the mechanisms described in this document. <ins> With post-handshake authentication there is also the possibility, though unlikely in practice, of multiple certificates and certificate chains from the client on a connection, in which case only the certificate and chain of the last post-handshake authentication are to be utilized for the header fields described herein. </ins> 2.
sufficiently smaller so as to allow for the addition of certificate data. <ins> 3.3. Some TLS implementations do not retain client certificate information when resuming.  Providing inconsistent values of Client-Cert and Client-Cert-Chain when resuming might lead to errors, so implementations that are unable to provide these values SHOULD either disable resumption for connections with client certificates or initially omit a "Client-Cert" or "Client-Cert-Chain" field if it might not be available after resuming. </ins> 4. The header fields described herein enable a TTRP and backend or
content with a length prefix, and a trailer section with a length prefix. <del> For a known-length encoding, the length prefix on field sections and content is a variable-length encoding of an integer.  This integer is the number of bytes in the field section or content. </del> Response messages that contain informational status codes result in a different structure; see informational.  Note that while the Known- Length Informational Response field is shown in format-known-length, it can only appear in response messages. <ins> For a known-length encoding, the length prefix on field sections and content is a variable-length encoding of an integer.  This integer is the number of bytes in the field section or content, not including the length field itself. </ins> Fields in the header and trailer sections consist of a length- prefixed name and length-prefixed value; see fields.
A message that is constructed without encoding a known length for each section uses the format shown in format-indeterminate-length: <del> That is, an indeterminate length consists of a framing indicator, a block of control data that is formatted according to the value of the framing indicator, a header section that is terminated by a zero value, any number of non-zero-length chunks of binary content, a zero value, and a trailer section that is terminated by a zero value. </del> <ins> That is, an indeterminate-length message consists of a framing indicator, a block of control data that is formatted according to the value of the framing indicator, a header section that is terminated by a zero value, any number of non-zero-length chunks of binary content, a zero value, and a trailer section that is terminated by a zero value. Response messages that contain informational status codes result in a different structure; see informational.  Note that while the Indeterminate-Length Informational Response field is shown in format- indeterminate-length, it can only appear in response messages. </ins> The indeterminate-length encoding only uses length prefixes for content blocks.  Multiple length-prefixed portions of content can be
distinguishes it from the Name Length field, which cannot contain a value of 0. <del> Response messages that contain informational status codes result in a different structure; see informational.  Note that while the Indeterminate-Length Informational Response field is shown in format- indeterminate-length, it can only appear in response messages. </del> Indeterminate-length messages can be truncated in a similar way as known-length messages; see padding.
format-informational. A response message can include any number of informational responses <del> that precede a final status code.  These convey an information status code and a header block. </del> <ins> that precede a final status code.  These convey an informational status code and a header block. </ins> If the response control data includes an informational status code (that is, a value between 100 and 199 inclusive), the control data is
3.1. <del> A message that has a known length at the time of construction uses the format shown in format-known-length. </del> <ins> A request or response that has a known length at the time of construction uses the format shown in format-known-length. </ins> <del> That is, a known-length message consists of a framing indicator, a block of control data that is formatted according to the value of the framing indicator, a header section with a length prefix, binary content with a length prefix, and a trailer section with a length prefix. </del> <ins> A known-length request consists of a framing indicator (framing), request control data (request-control), a header section with a length prefix, binary content with a length prefix, a trailer section with a length prefix, and padding. </ins> <del> Response messages that contain informational status codes result in a different structure; see informational.  Note that while the Known- Length Informational Response field is shown in format-known-length, it can only appear in response messages. </del> <ins> A known-length response contains the same fields, with the exception that request control data is replaced by zero or more informational responses (informational) followed by response control data (response-control). </ins> For a known-length encoding, the length prefix on field sections and content is a variable-length encoding of an integer.  This integer is
3.2. <del> A message that is constructed without encoding a known length for each section uses the format shown in format-indeterminate-length: </del> <ins> A request or response that is constructed without encoding a known length for each section uses the format shown in format- indeterminate-length: </ins> <del> That is, an indeterminate-length message consists of a framing indicator, a block of control data that is formatted according to the value of the framing indicator, a header section that is terminated by a zero value, any number of non-zero-length chunks of binary content, a zero value, and a trailer section that is terminated by a zero value. </del> <ins> An indeterminate-length request consists of a framing indicator (framing), request control data (request-control), a header section that is terminated by a zero value, any number of non-zero-length chunks of binary content, a zero value, a trailer section that is terminated by a zero value, and padding. </ins> <del> Response messages that contain informational status codes result in a different structure; see informational.  Note that while the Indeterminate-Length Informational Response field is shown in format- indeterminate-length, it can only appear in response messages. </del> <ins> An indeterminate-length response contains the same fields, with the exception that request control data is replaced by zero or more informational responses (informational) and response control data (response-control). </ins> The indeterminate-length encoding only uses length prefixes for content blocks.  Multiple length-prefixed portions of content can be
contains a digest value computed by applying a hashing algorithm to selected representation data (SEMANTICS).  Basing "Repr-Digest" on the selected representation makes it straightforward to apply it to <del> use-cases where the transferred data requires some sort of manipulation to be considered a representation or conveys a partial representation of a resource, such as Range Requests (see SEMANTICS). </del> <ins> use-cases where the message content requires some sort of manipulation to be considered as representation of the resource or content conveys a partial representation of a resource, such as Range Requests (see SEMANTICS). </ins> "Content-Digest" and "Repr-Digest" support hashing algorithm agility. The "Want-Content-Digest" and "Want-Repr-Digest" fields allow endpoints to express interest in "Content-Digest" and "Repr-Digest" <del> respectively, and preference of algorithms in either. </del> <ins> respectively, and to express algorithm preferences in either. </ins> "Content-Digest" and "Repr-Digest" are collectively termed Integrity fields.  "Want-Content-Digest" and "Want-Repr-Digest" are
framing, which describes whether the message is a request or response and how subsequent sections are formatted; see framing. <del> For a response, any number of interim responses, each consisting of an informational status code and header section. </del> <ins> For a response, any number of informational responses, each consisting of an informational status code and header section. </ins> Control data.  For a request, this contains the request method and target.  For a response, this contains the status code.
for the semantics of repeated field names and rules for combining values. <ins> Messages are invalid (invalid) if they contain fields named ":method", ":scheme", ":authority", ":path", or ":status".  Other pseudo-fields that are defined by protocol extensions MAY be included; pseudo-fields cannot be included in trailers (see H2). Field lines containing pseudo-fields MUST precede other field lines. A message that contains a pseudo-field after any other field is invalid; see invalid. </ins> Fields that relate to connections (HTTP) cannot be used to produce the effect on a connection in this context.  These fields SHOULD be removed when constructing a binary message.  However, they do not cause a message to be invalid (invalid); permitting these fields <del> allows a binary message to capture the content of a messages that are exchanged in a protocol context. </del> <ins> allows a binary message to capture messages that are exchanged in a protocol context. </ins> <del> Like HTTP/2, this format has an exception for the combination of multiple instances of the "Cookie" field.  Instances of fields with the ASCII-encoded value of "cookie" are combined using a semicolon octet (0x3b) rather than a comma; see H2. </del> <ins> Like HTTP/2 or HTTP/3, this format has an exception for the combination of multiple instances of the "Cookie" field.  Instances of fields with the ASCII-encoded value of "cookie" are combined using a semicolon octet (0x3b) rather than a comma; see H2. </ins> 3.7.
This can be expressed as a binary message (type "message/bhttp") using a known-length encoding as shown in hexadecimal in ex-bink- <del> request.  ex-bink-request view includes some of the text alongside to show that most of the content is not modified. </del> <ins> request.  ex-bink-request includes text alongside to show that most of the content is not modified. </ins> This example shows that the Host header field is not replicated in <del> the :authority field, as is required for ensuring that the request is reproduced accurately; see H2. </del> <ins> the ":authority" field, as is required for ensuring that the request is reproduced accurately; see H2. </ins> The same message can be truncated with no effect on interpretation. In this case, the last two bytes - corresponding to content and a
Some of these features are also absent in HTTP/2 and HTTP/3. Unlike HTTP/2 and HTTP/3, this format uses a fixed format for control <del> data rather than using pseudo-fields.  Messages are invalid (invalid) if they contain fields named ":method", ":scheme", ":authority", ":path", or ":status".  Other pseudo-fields that are defined by protocol extensions MAY be included; pseudo-fields cannot be included in trailers (see H2).  Field lines containing pseudo-fields MUST precede other field lines.  A message that contains a pseudo-field after any other field is invalid; see invalid. </del> <ins> data rather than using pseudo-fields. </ins> Note that while some messages - CONNECT or upgrade requests in particular - can be represented using this format, doing so serves no