jiebi/CodeConvo huggingface dataset:
the "..[*]" and "..*" forms select all the descendants. <del> The resultant nodelist is ordered as if: </del> <ins> An </ins> <del> nodes are visited before their children, and </del> <ins> of the descendants of a node is a sequence of all the descendants in which: </ins> <del> nodes of an array are visited in array order. </del> <ins> nodes of any array appear in array order, </ins> <del> Children of an object may be visited in any order, since JSON objects are unordered. </del> <ins> nodes appear immediately before all their descendants. </ins> <del> Implementations may visit descendants in any way providing the resultant nodelist could have been produced by visiting descendants as above. </del> <ins> This definition does not stipulate the order in which the children of an object appear, since JSON objects are unordered. The resultant nodelist of a "descendant-selector" applied to a node must be a sub-sequence of an array-sequenced preorder of the descendants of the node. </ins> 3.5.7.3.
3.5.5.2.2. <del> The comparison operators "==", "<", and ">" are defined first and then these are used to define "!=", "<=", and ">=". </del> <ins> The comparison operators "==" and "<" are defined first and then these are used to define "!=", "<=", ">", and ">=". </ins> When a path resulting in an empty nodelist appears on either side of a comparison:
for each of those names, the values associated with the name by the objects are equal. <del> a comparison using either of the operators "<" or ">" yields true if and only if the comparison is between values of the same type which are both numbers or both strings and which satisfy the comparison: </del> <ins> a comparison using the operator "<" yields true if and only if the comparison is between values of the same type which are both numbers or both strings and which satisfy the comparison: </ins> numbers expected to interoperate as per RFC7493 MUST compare using the normal mathematical ordering; numbers not expected to
first string compares less than the remainder of the second string. <del> Note that comparisons using either of the operators "<" or ">" yield false if either value being compared is an object, array, boolean, or "null". </del> <ins> Note that comparisons using the operator "<" yield false if either value being compared is an object, array, boolean, or "null". </ins> <del> "!=", "<=" and ">=" are defined in terms of the other comparison operators.  For any "a" and "b": </del> <ins> "!=", "<=", ">", and ">=" are defined in terms of the other comparison operators.  For any "a" and "b": </ins> The comparison "a != b" yields true if and only if "a == b" yields false.
The comparison "a <= b" yields true if and only if "a < b" yields true or "a == b" yields true. <del> The comparison "a >= b" yields true if and only if "a > b" yields </del> <ins> The comparison "a > b" yields true if and only if "b < a" yields true. The comparison "a >= b" yields true if and only if "b < a" yields </ins> true or "a == b" yields true. 3.5.5.2.3.
4.2. <ins> JSONPath queries are often not static, but formed from variables that provide index values, member names, or values to compare with in a filter expression.  These variables need to be translated into the form they take in a JSONPath query, e.g., by escaping string delimiters, or by only allowing specific constructs such as ".name" to be formed when the given values allow that.  Failure to perform these translations correctly can lead to unexpected failures, which can lead to Availability, Confidentiality, and Integrity breaches, in particular if an adversary has control over the values (e.g., by entering them into a Web form).  The resulting class of attacks, (e.g., SQL injections), is consistently found among the top causes of application security vulnerabilities and requires particular attention. 4.3. </ins> Where JSONPath is used as a part of a security mechanism, attackers can attempt to provoke unexpected or unpredictable behavior, or take advantage of differences in behavior between JSONPath
filter-selectors enclosing the filter-selector that is directly enclosing the identifier). <del> An existence expression may test the result of a function expression (see fnex). </del> <ins> A test expression either tests the existence of a node designated by an embedded query (see extest) or tests the result of a function expression (see fnex).  In the latter case, if the function expression is of type "OptionalBoolean" or one of its subtypes, it tests whether the result is "true"; if the function expression is of type "OptionalNodes" or one of its subtypes, it tests whether the result is different from "Nothing". </ins> Parentheses MAY be used within "boolean-expr" for grouping.
Comparison expressions are available for comparisons between primitive values (that is, numbers, strings, "true", "false", and <del> "null").  These can be obtained via literal values; Singular Paths, </del> <ins> "null").  These can be obtained via literal values; Singular Queries, </ins> each of which selects at most one node the value of which is then used; and function expressions (see fnex) of type "ValueType" or "NodesType" (see type-conv).
2.5.5.2.1. <del> A path by itself in a Logical context is an existence test which yields true if the path selects at least one node and yields false if the path does not select any nodes. </del> <ins> A query by itself in a Logical context is an existence test which yields true if the query selects at least one node and yields false if the query does not select any nodes. </ins> Existence tests differ from comparisons in that: <del> they work with arbitrary relative or absolute paths (not just Singular Paths). </del> <ins> they work with arbitrary relative or absolute queries (not just Singular Queries). </ins> <del> they work with paths that select structured values. </del> <ins> they work with queries that select structured values. </ins> <del> To examine the value of a node selected by a path, an explicit </del> <ins> To examine the value of a node selected by a query, an explicit </ins> comparison is necessary.  For example, to test whether the node <del> selected by the path "@.foo" has the value "null", use "@.foo == </del> <ins> selected by the query "@.foo" has the value "null", use "@.foo == </ins> null" (see null-semantics) rather than the negated existence test "!@.foo" (which yields false if "@.foo" selects a node, regardless of the node's value).
implementation level only -- they do not influence the result of the evaluation.) <del> A function argument is a "filter-path" or a "comparable". </del> <ins> A function argument is a "filter-query" or a "comparable". </ins> According to filter-selector, a "function-expr" is valid as a <del> "filter-path" or a "comparable". </del> <ins> "filter-query" or a "comparable". </ins> Any function expressions in a query must be well-formed (by conforming to the above ABNF) and well-typed, otherwise the JSONPath
related to the JSON literals "true" and "false" and have no direct syntactical representation in JSONPath. <del> "NodesType" is an abstraction of a "filter-path" (which appears in a test expression or as a function argument).  Members of </del> <ins> "NodesType" is an abstraction of a "filter-query" (which appears in a test expression or as a function argument).  Members of </ins> "NodesType" have no direct syntactical representation in JSONPath. The abstract instances above can be obtained from the concrete
The argument is a literal primitive value and the defined type of the parameter is "ValueType". <del> The argument is a Singular Path or "filter-path" (which includes Singular Paths), or a function expression with </del> <ins> The argument is a Singular Query or "filter-query" (which includes Singular Queries), or a function expression with </ins> declared result type "NodesType" and the defined type of the parameter is "NodesType".  Where the declared type of the parameter is not "NodesType", a conversion applies.
Certain characters are escaped, in one and only one way; all other characters are unescaped. <del> Note: Normalized Paths are Singular Paths, but not all Singular Paths are Normalized Paths.  For example, "$[-3]" is a Singular Path, but is not a Normalized Path.  The Normalized Path equivalent to "$[-3]" would have an index equal to the array length minus "3".  (The array length must be at least "3" if "$[-3]" is to identify a node.) </del> <ins> Note: Normalized Paths are Singular Queries, but not all Singular Queries are Normalized Paths.  For example, "$[-3]" is a Singular Query, but is not a Normalized Path.  The Normalized Path equivalent to "$[-3]" would have an index equal to the array length minus "3". (The array length must be at least "3" if "$[-3]" is to identify a node.) </ins> Since there can only be one Normalized Path identifying a given node, the syntax stipulates which characters are escaped and which are not.
Comparison expressions are available for comparisons between primitive values (that is, numbers, strings, "true", "false", and <del> "null").  These can be obtained via literal values; Singular Queries, </del> <ins> "null").  These can be obtained via literal values; singular queries, </ins> each of which selects at most one node the value of which is then used; or function expressions (see fnex) of type "ValueType".
Certain characters are escaped in Normalized Paths, in one and only one way; all other characters are unescaped. <del> Note: Normalized Paths are Singular Queries, but not all Singular Queries are Normalized Paths.  For example, "$[-3]" is a singular </del> <ins> Note: Normalized Paths are singular queries, but not all singular queries are Normalized Paths.  For example, "$[-3]" is a singular </ins> query, but is not a Normalized Path.  The Normalized Path equivalent to "$[-3]" would have an index equal to the array length minus "3". (The array length must be at least "3" if "$[-3]" is to identify a
, as described in fnex. A JSONPath implementation MUST raise an error for any query which is <del> not well-formed and valid.  The well-formedness and the validity of </del> <ins> not well formed and valid.  The well-formedness and the validity of </ins> JSONPath queries are independent of the JSON value the query is applied to.  No further errors relating to the well-formedness and the validity of a JSONPath query can be raised during application of
implementation level only -- they do not influence the result of the evaluation.) <del> Any function expressions in a query must be well-formed (by conforming to the above ABNF) and well-typed, otherwise the JSONPath </del> <ins> Any function expressions in a query must be well formed (by conforming to the above ABNF) and well typed, otherwise the JSONPath </ins> implementation MUST raise an error (see synsem-overview).  To define <del> which function expressions are well-typed, a type system is first </del> <ins> which function expressions are well typed, a type system is first </ins> introduced. 2.6.1.
If the argument is "Nothing" or contains multiple nodes, the result is "Nothing". <del> Note: a Singular Query may be used anywhere where a ValueType is </del> <ins> Note: a singular query may be used anywhere where a ValueType is </ins> expected, so there is no need to use the "value" function extension <del> with a Singular Query. </del> <ins> with a singular query. </ins> 2.6.9.
one way; all other characters are unescaped. Note: Normalized Paths are Singular Queries, but not all Singular <del> Queries are Normalized Paths.  For example, "$[-3]" is a Singular Query, but is not a Normalized Path.  The Normalized Path equivalent </del> <ins> Queries are Normalized Paths.  For example, "$[-3]" is a singular query, but is not a Normalized Path.  The Normalized Path equivalent </ins> to "$[-3]" would have an index equal to the array length minus "3". (The array length must be at least "3" if "$[-3]" is to identify a node.)
example, the Unicode PLACE OF INTEREST SIGN (U+2318) would be defined in ABNF as "%x2318". <ins> Functions are referred to using the function name followed by a pair of parentheses, as in "fname()". </ins> The terminology of RFC8259 applies except where clarified below.  The terms "Primitive" and "Structured" are used to group different kinds of values as in RFC8259; JSON Objects and Arrays are structured, all
2.3.2.2. <del> A "wildcard" selector selects the nodes of all children of an object or array.  The order in which the children of an object appear in the </del> <ins> A wildcard selector selects the nodes of all children of an object or array.  The order in which the children of an object appear in the </ins> resultant nodelist is not stipulated, since JSON objects are unordered.  Children of an array appear in array order in the resultant nodelist. <del> The "wildcard" selector selects nothing from a primitive JSON value </del> <ins> The wildcard selector selects nothing from a primitive JSON value </ins> (that is, a number, a string, "true", "false", or "null"). 2.3.2.3.
If the nodelist is empty, the conversion result is "LogicalFalse". <del> Extraction of a value from a nodelist can be performed in several ways, so an implicit conversion from "NodesType" to "ValueType" may be surprising and has therefore not been defined.  A function expression with a declared type of "NodesType" can indirectly be used as an argument for a parameter of declared type "ValueType" by wrapping the expression in a call to a function extension such as "value" (see value). </del> <ins> Notes: Extraction of a value from a nodelist can be performed in several ways, so an implicit conversion from "NodesType" to "ValueType" may be surprising and has therefore not been defined. A function expression with a declared type of "NodesType" can indirectly be used as an argument for a parameter of declared type "ValueType" by wrapping the expression in a call to a function extension, such as "value()" (see value), that takes a parameter of type "NodesType" and returns a result of type "ValueType". </ins> The well-typedness of function expressions can now be defined in terms of this type system.
2.4.4. <del> The "length" function extension provides a way to compute the length of a value and make that available for further processing in the filter expression: </del> <ins> The "length()" function extension provides a way to compute the length of a value and make that available for further processing in the filter expression: </ins> Its only argument is an instance of "ValueType" (possibly taken from a singular query, as in the example above).  The result also is an
2.4.5. <del> The "count" function extension provides a way to obtain the number of nodes in a nodelist and make that available for further processing in the filter expression: </del> <ins> The "count()" function extension provides a way to obtain the number of nodes in a nodelist and make that available for further processing in the filter expression: </ins> Its only argument is a nodelist.  The result is a value, an unsigned integer, that gives the number of nodes in the nodelist.  Note that
2.4.8. <del> The "value" function extension provides a way to convert an instance of "NodesType" to a value and make that available for further processing in the filter expression: </del> <ins> The "value()" function extension provides a way to convert an instance of "NodesType" to a value and make that available for further processing in the filter expression: </ins> Its only argument is an instance of "NodesType" (possibly taken from a "filter-query", as in the example above).  The result is an
If an endpoint receives an ADDRESS_REQUEST capsule that contains zero Requested Addresses, it MUST abort the IP proxying request stream. <ins> Note that the ordering of Requested Addresses does not carry any semantics.  Similarly, the Request ID is only meant as a unique identifier, it does not convey any priority or importance. </ins> 4.7.3. The ROUTE_ADVERTISEMENT capsule (see iana-types for the value of the
meet these requirements, it MUST abort the IP proxying request stream. <ins> Since setting the IP protocol to zero indicates all protocols are allowed, the requirements above make it possible for two routes to overlap when one has IP protocol set to zero and the other set to non-zero.  Endpoints MUST not send a ROUTE_ADVERTISEMENT capsule with routes that overlap in such a way.  Validating this requirement is OPTIONAL, but if an endpoint detects the violation, it MUST abort the IP proxying request stream. </ins> 5. The mechanism for proxying IP in HTTP defined in this document allows
of the destinations included in the scope, then the IP proxy can immediately fail the request. <ins> Note that IP protocol numbers represent both upper layers (as defined in IPv6, examples include TCP and UDP) and IPv6 extension headers (as defined in IPv6, examples include Fragment and Options headers).  IP proxies MAY reject requests to scope to protocol numbers that are used for extension headers.  Upon receiving packets, implementations that support scoping by IP protocol number MUST walk the chain of extensions to find the matching IP protocol number. </ins> 4.7. This document defines multiple new capsule types that allow endpoints
ADDRESS_REQUEST capsules, endpoints MAY send ADDRESS_ASSIGN capsules unprompted. <ins> Note that the IP forwarding tunnels described in this document are not fully featured "interfaces" in the IPv6 addressing architecture sense IPv6-ADDR.  In particular, they do not necessarily have IPv6 link-local addresses.  Additionally, IPv6 stateless autoconfiguration or router advertisement messages are not used in such interfaces, and neither is neighbor discovery. </ins> 4.7.2. The ADDRESS_REQUEST capsule (see iana-types for the value of the
Datagram.  This prevents infinite loops in the presence of routing loops, and matches the choices in IPsec IPSEC. <ins> Implementers need to ensure that they do not forward any link-local traffic onto a different interface than the one it was received on. IP proxies also need to properly reply to packets destined to link- local multicast addresses. </ins> IPv6 requires that every link have an MTU of at least 1280 bytes IPv6.  Since IP proxying in HTTP conveys IP packets in HTTP Datagrams and those can in turn be sent in QUIC DATAGRAM frames which cannot be
Upon receiving the ROUTE_ADVERTISEMENT capsule, an endpoint MAY start routing IP packets in that prefix to its peer. <ins> If an endpoint receives multiple ROUTE_ADVERTISEMENT capsules, all of the advertised routes can be used.  For example, multiple ROUTE_ADVERTISEMENT capsules are necessary to provide routing to both IPv4 and IPv6 hosts.  Routes are removed using ROUTE_WITHDRAWAL capsules. </ins> 4.2.4. The ROUTE_WITHDRAWAL capsule allows an endpoint to communicate to its
endpoint that receives packets for routes it has rejected MUST NOT treat that as an error. <ins> ROUTE_ADVERTISEMENT and ROUTE_WITHDRAWAL capsules are applied in order of receipt: if a prefix is covered by multiple received ROUTE_ADVERTISEMENT and/or ROUTE_WITHDRAWAL capsules, only the last received capsule applies as it supersedes prior ROUTE_ADVERTISEMENT and ROUTE_WITHDRAWAL capsules for this prefix. </ins> 5. IP packets are sent using HTTP Datagrams I-D.ietf-masque-h3-datagram.
4.2.1. <del> The ADDRESS_ASSIGN capsule allows an endpoint to inform its peer that it has assigned an IP address to it.  It allows assigning a prefix which can contain multiple addresses.  This capsule uses a Capsule Type of 0xfff100.  Its value uses the following format: </del> <ins> The ADDRESS_ASSIGN capsule (see iana-types for the value of the capsule type) allows an endpoint to inform its peer that it has assigned an IP address or prefix to it.  The ADDRESS_ASSIGN capsule allows assigning a prefix which can contain multiple addresses.  Any of these addresses can be used as the source address on IP packets originated by the receiver of this capsule. </ins> IP Version of this address assignment.  MUST be either 4 or 6.
4.2.2. <del> The ADDRESS_REQUEST capsule allows an endpoint to request assignment of an IP address from its peer.  This capsule is not required for simple client/proxy communication where the client only expects to receive one address from the proxy.  The capsule allows the endpoint to optionally indicate a preference for which address it would get assigned.  This capsule uses a Capsule Type of 0xfff101.  Its value uses the following format: </del> <ins> The ADDRESS_REQUEST capsule (see iana-types for the value of the capsule type) allows an endpoint to request assignment of an IP address from its peer.  This capsule is not required for simple client/proxy communication where the client only expects to receive one address from the proxy.  The capsule allows the endpoint to optionally indicate a preference for which address it would get assigned. </ins> IP Version of this address request.  MUST be either 4 or 6.
or split-tunnel. In this case, the client does not specify any scope in its request. <del> The server assigns the client an IPv6 address prefix to the client (2001:db8::/64) and a full-tunnel route of all IPv6 addresses (::/0). The client can then send to any IPv6 host using a source address in its assigned prefix. </del> <ins> The server assigns the client an IPv4 address to the client (192.0.2.11) and a full-tunnel route of all IPv4 addresses (0.0.0.0/0).  The client can then send to any IPv4 host using a source address in its assigned prefix. </ins> A setup for a split-tunnel VPN (the case where the client can only access a specific set of private subnets) is quite similar.  In this <del> case, the advertised route is restricted to 2001:db8::/32, rather than ::/0. </del> <ins> case, the advertised route is restricted to 192.0.2.0/24, rather than 0.0.0.0/0. </ins> 6.2.
Unlike CONNECT-UDP requests, which require specifying a target host, CONNECT-IP requests can allow endpoints to send arbitrary IP packets to any host.  The client can choose to restrict a given request to a <del> specific host or IP protocol by adding parameters to its request. When the server knows that a request is scoped to a target host or </del> <ins> specific prefix or IP protocol by adding parameters to its request. When the server knows that a request is scoped to a target prefix or </ins> protocol, it can leverage this information to optimize its resource allocation; for example, the server can assign the same public IP <del> address to two CONNECT-IP requests that are scoped to different hosts and/or different protocols. </del> <ins> address to two CONNECT-IP requests that are scoped to different prefixes and/or different protocols. </ins> CONNECT-IP uses URI template variables (client-config) to determine the scope of the request for packet proxying.  All variables defined
an HTTP Datagram.  This prevents infinite loops in the presence of routing loops, and matches the choices in IPsec IPSEC. <ins> IPv6 requires that every link have an MTU of at least 1280 bytes IPv6.  Since CONNECT-IP conveys IP packets in HTTP Datagrams and those can in turn be sent in QUIC DATAGRAM frames which cannot be fragmented DGRAM, the MTU of a CONNECT-IP link can be limited by the MTU of the QUIC connection that CONNECT-IP is operating over.  This can lead to situations where the IPv6 minimum link MTU is violated. CONNECT-IP endpoints that support IPv6 MUST ensure that the CONNECT- IP tunnel link MTU is at least 1280 (i.e., that they can send HTTP Datagrams with payloads of at least 1280 bytes).  This can be accomplished using various techniques: if HTTP intermediaries are not in use, both CONNECT-IP endpoints can pad the QUIC INITIAL packets of the underlying QUIC connection that CONNECT-IP is running over. if HTTP intermediaries are in use, CONNECT-IP endpoints can enter in an out of band agreement with the intermediaries to ensure that endpoints and intermediaries pad QUIC INITIAL packets. CONNECT-IP endpoints can also send ICMPv6 echo requests with 1232 bytes of data to ascertain the link MTU and tear down the tunnel if they do not receive a response.  Unless endpoints have an out of band means of guaranteeing that one of the two previous techniques is sufficient, they MUST use this method. </ins> Endpoints MAY implement additional filtering policies on the IP packets they forward.