jiebi/CodeConvo huggingface dataset:
2.3. <ins> HTTP caching has a single, end-to-end freshness model defined in Section 4.2 of I-D.ietf-httpbis-cache.  When additional freshness mechanisms are only available to some caches along a request path (for example, using targeted fields), their interactions need to be carefully considered.  In particular, a targeted cache might have longer freshness lifetimes available to it than other caches, causing it to serve responses that appear to be prematurely (or even immediately) stale to them, negatively impacting cache efficiency. For example, a response stored by a CDN cache might be served with the following headers: From the CDN's perspective, this response is still fresh after being cached for 30 minutes, while from other caches' standpoint, this response is already stale.  See AGE-PENALTY for more discussion. When the targeted cache has a strong coherence mechanism (e.g., the origin server has the ability to proactively invalidate cached responses), it is often desirable to mitigate these effects.  Some techniques seen in deployments include: Removing the Age header field Updating the Date header field value to the current time Updating the Expires header field value to the current time, plus any Cache-Control: max-age value This specification does not place any specific requirements on implementations to mitigate these effects, but definitions of targeted fields can do so. 2.4. </ins> A targeted field for a particular class of cache can be defined by requesting registration in the Hypertext Transfer Protocol (HTTP) Field Name Registry https://www.iana.org/assignments/http-fields/
This document describes a use of HTTP Alternative Services I-D.ietf- httpbis-alt-svc to decouple the URI scheme from the use and configuration of underlying encryption, allowing a "http" URI RFC7230 <del> to be accessed using TLS RFC5246 opportunistically. </del> <ins> to be accessed using Transport Layer Security (TLS) RFC5246 opportunistically. </ins> Serving "https" URIs require acquiring and configuring a valid certificate, which means that some deployments find supporting TLS
the alternative service can provide any certificate, or even select TLS cipher suites that do not include authentication. <del> When the client has a valid http-opportunistic response for an origin, it MAY consider there to be reasonable assurances when: </del> <ins> A client acquires an http-opportunistic response by making a GET request to the "http-opportunistic" well-known URI.  When the client has a valid http-opportunistic response for an origin, it MAY consider there to be reasonable assurances when: </ins> The origin and alternative service's hostnames are the same when compared in a case-insensitive fashion, and
is initially created for "http" URIs without authenticating the server cannot be used for "https" URIs until the server certificate is successfully authenticated.  Section 3.1 of RFC2818 describes the <del> basic mechanism, though the authentication considerations in I- D.ietf-httpbis-alt-svc also apply. </del> <ins> basic mechanism, though the authentication considerations in Section 2.1 of I-D.ietf-httpbis-alt-svc also apply. </ins> Connections that are established without any means of server <del> authentication (for instance, the purely anonymous TLS cipher suites), cannot be used for "https" URIs. </del> <ins> authentication (for instance, the purely anonymous TLS cipher suites) cannot be used for "https" URIs. </ins> 5.
The "origins" member of the root object has a value of an array of strings, one of which is a case-insensitive character-for- character match for the origin in question, serialised into <del> Unicode as per RFC6454, Section 6.1, and </del> <ins> Unicode as per Section 6.1 of RFC6454. </ins> This specification defines one additional, optional member of the root object, "commit" in commit.  Unrecognised members MUST be
8.2. A downgrade attack against the negotiation for TLS is possible.  With <del> commitment commit, this is limited to occasions where clients have no prior information (see privacy), or when persisted commitments have expired. </del> <ins> commitment (see commit), this is limited to occasions where clients have no prior information (see privacy), or when persisted commitments have expired. </ins> For example, because the "Alt-Svc" header field I-D.ietf-httpbis-alt- svc likely appears in an unauthenticated and unencrypted channel, it
8.4. <del> Many existing HTTP/1.1 implementations use the presence or absence of TLS in the stack to determine whether requests are for "http" or "https" resources.  This is necessary in many cases because the most common form of an HTTP/1.1 request does not carry an explicit indication of the URI scheme. HTTP/1.1 MUST NOT be used for opportunistically secured requests. </del> Some HTTP/1.1 implementations use ambient signals to determine if a request is for an "https" resource.  For example, implementations <del> might look for TLS on the stack or a port number of 443.  An implementation that supports opportunistically secured requests SHOULD suppress these signals if there is any potential for confusion. </del> <ins> might look for TLS on the stack or a port number of 443.  This is necessary in many cases because the most common form of an HTTP/1.1 request does not carry an explicit indication of the URI scheme.  An implementation that is serving an opportunistically secured request SHOULD suppress these signals for "http" resources. HTTP/1.1 MUST NOT be used to serve opportunistically secured requests.  HTTP/1.1 can be used to discover an opportunistically secured alternative service. </ins> 9.  References
The "next-protocol" parameter's value indicates the ALPN protocol identifier RFC7301 of the protocol used by the intermediary to <del> connect to the next hop.  This is only applicable when that connection was actually established. </del> <ins> connect to the next hop when obtaining this response. </ins> The value MUST be either an sf-token or sf-binary, representing a TLS Application-Layer Protocol Negotiation (ALPN) Protocol ID (see
There are many ways that a client could discover the alternative service(s) associated with an origin.  This document describes two such mechanisms: the "Alt-Svc" HTTP header field (alt-svc-field) and <del> the "ALTSVC" HTTP/2 frame type (ALTSVC-frame). </del> <ins> the "ALTSVC" frame type for HTTP/2 and HTTP/3 (ALTSVC-frame). </ins> The remainder of this section describes requirements that are common to alternative services, regardless of how they are discovered.
4. <del> The ALTSVC HTTP/2 frame (Section 4 of HTTP2) advertises the availability of an alternative service to an HTTP/2 client. </del> <ins> The ALTSVC frame advertises the availability of an alternative service to an HTTP/2 or HTTP/3 client. </ins> <del> The ALTSVC frame is a non-critical extension to HTTP/2.  Endpoints that do not support this frame will ignore it (as per the extensibility rules defined in Section 4.1 of HTTP2). </del> <ins> The ALTSVC frame is a separate non-critical extension in each protocol.  Endpoints that do not support this frame will ignore it (as per the extensibility rules defined in Section 4.1 of HTTP2 and Section 4.1 of HTTP3). </ins> <del> An ALTSVC frame from a server to a client on a stream other than stream 0 indicates that the conveyed alternative service is </del> <ins> An ALTSVC frame from a server to a client on a request stream or a push stream indicates that the conveyed alternative service is </ins> associated with the origin of that stream. <del> An ALTSVC frame from a server to a client on stream 0 indicates that </del> <ins> An ALTSVC frame from a server to a client on the control stream (stream 0 in HTTP/2 or a stream of type 0 in HTTP/3) indicates that </ins> the conveyed alternative service is associated with the origin contained in the Origin field of the frame.  An association with an origin that the client does not consider authoritative for the current connection MUST be ignored. <del> The ALTSVC frame type is 0xa (decimal 10). </del> <ins> The ALTSVC frame type is 0xa (decimal 10) in both protocols. </ins> The ALTSVC frame contains the following fields:
identical to the Alt-Svc field value defined in alt-svc-field (ABNF production "Alt-Svc"). <del> The ALTSVC frame does not define any flags. </del> <ins> The ALTSVC frame does not define any flags in HTTP/2; there is no generic flag field for HTTP/3 frames. </ins> The ALTSVC frame is intended for receipt by clients.  A device acting as a server MUST ignore it. <del> An ALTSVC frame on stream 0 with empty (length 0) "Origin" </del> <ins> An ALTSVC frame on the control stream with empty (length 0) "Origin" </ins> information is invalid and MUST be ignored.  An ALTSVC frame on a <del> stream other than stream 0 containing non-empty "Origin" information is invalid and MUST be ignored. </del> <ins> request or push stream containing non-empty "Origin" information is invalid and MUST be ignored. </ins> The ALTSVC frame is processed hop-by-hop.  An intermediary MUST NOT forward ALTSVC frames, though it can use the information contained in
7.3. <ins> This document registers the ALTSVC frame type in the "HTTP/3 Frame Type" registry (Section 11.2.1 of HTTP3). ALTSVC 0xa ALTSVC-frame of this document 7.4. </ins> The "Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter Registry" defines the name space for parameters.  It has been created and will be maintained at <http://www.iana.org/assignments/http-alt-svc- parameters>. <del> 7.3.1. </del> <ins> 7.4.1. </ins> A registration MUST include the following fields:
is preferred; digest-algorithm token values MUST be compared in a case-insensitive fashion. <ins> Every digest-algorithm defines its computation procedure and encoding output.  Unless specified otherwise, comparison of encoded output is case-sensitive. </ins> The "HTTP Digest Algorithm Values Registry", maintained by IANA at https://www.iana.org/assignments/http-dig-alg/ [3] registers digest- algorithm values.  Registrations MUST include the following fields:
This memo sets this specification to be the establishing document for the HTTP Digest Algorithm Values [4] registry. <ins> IANA is asked to update the "Reference" for this registry to refer this document and to inizialize the registry with the tokens defined in algorithms. This registry uses the Specification Required policy (Section 4.6 of RFC8126). </ins> 13.2. This memo adds the "contentMD5" token in the HTTP Digest Algorithm
13.3. <del> &#65532; The "contentMD5" digest-algorithm token defined in Section 5 of RFC3230 is removed from the HTTP Digest Algorithm Values Registry. </del> <ins> The "contentMD5" digest-algorithm token defined in Section 5 of RFC3230 has been added to the HTTP Digest Algorithm Values Registry with the "obsoleted" status. </ins> All digest-algorithms defined in RFC3230 are now "deprecated". 13.4. <del> The digest-algorithm values for "MD5", "SHA", "SHA-256", "SHA-512" </del> <ins> The digest-algorithm tokens for "MD5", "SHA", "SHA-256", "SHA-512" </ins> have been updated to lowercase. The status of "MD5" and "SHA" has been updated to "deprecated", and <del> their description states that they MUST NOT be used. </del> <ins> their description has been modified accordingly. </ins> The "id-sha-256" and "id-sha-512" algorithms have been added to the registry.
2. A Targeted Cache-Control Header Field (hereafter, "targeted field") <del> is a HTTP response header field that has the same syntax and semantics as the Cache-Control response header field I-D.ietf- httpbis-cache, Section 5.2.  However, it has a distinct field name that indicates the target for its directives. </del> <ins> is a HTTP response header field that has the same semantics as the Cache-Control response header field (HTTP-CACHING, Section 5.2). However, it has a distinct field name that indicates the target for its directives. </ins> For example:
Note that this occurs on a response-by-response basis; if no member of the cache's target list is present, valid and non-empty, a cache <del> falls back to other cache control mechanisms as required by HTTP I- D.ietf-httpbis-cache. </del> <ins> falls back to other cache control mechanisms as required by HTTP HTTP-CACHING. </ins> Targeted fields that are not on a cache's target list MUST NOT change that cache's behaviour, and MUST be passed through.
uses HTTPS exclusively. Servers can partially mitigate these attacks by encrypting and <del> signing the contents of their cookies.  However, using cryptography does not mitigate the issue completely because an attacker can replay a cookie he or she received from the authentic site.example server in the user's session, with unpredictable results. </del> <ins> signing the contents of their cookies, or by naming the cookie with the "__Secure-" prefix.  However, using cryptography does not mitigate the issue completely because an attacker can replay a cookie he or she received from the authentic site.example server in the user's session, with unpredictable results. </ins> Finally, an attacker might be able to force the user agent to delete cookies by storing a large number of cookies.  Once the user agent
RFC6455 over a single stream of an HTTP/2 connection.  It defines an Extended CONNECT method which specifies a new ":protocol" pseudo header field and new semantics for the ":path" and ":authority" <del> pseudo header fields.  It also defines a new HTTP/2 SETTING sent by a </del> <ins> pseudo header fields.  It also defines a new HTTP/2 setting sent by a </ins> server to allow the client to use Extended CONNECT. The HTTP/3 stream closure is also analogous to the TCP connection
FIN bit on the stream (HTTP3).  RST exceptions are represented with an stream error (HTTP3) of type H3_REQUEST_CANCELLED (HTTP3) <del> The semantics of the headers and SETTING are identical to those in </del> <ins> The semantics of the headers and setting are identical to those in </ins> HTTP/2 as defined RFC8441.  HTTP3 requires that HTTP/3 settings be registered separately for HTTP/3.  The SETTINGS_ENABLE_CONNECT_PROTOCOL value is 0x08 (decimal 8), as in
Abstract The mechanism for running the WebSocket Protocol over a single stream <del> of an HTTP/2 connection is equally applicable to HTTP/3, but needs to be separately registered.  This document describes the mechanism for HTTP/3. </del> <ins> of an HTTP/2 connection is equally applicable to HTTP/3, but the HTTP version-specific details need to be specified.  This document describes how the mechanism is adapted for HTTP/3. </ins> Note to Readers
The SETTINGS_NO_RFC7540_PRIORITIES setting is defined by this document in order to allow endpoints to explicitly opt out of using HTTP/2 priority signals (see Section 5.3.2 of HTTP2).  Endpoints are <del> expected to use an alternative, such as the scheme defined in this specification. </del> <ins> encouraged to use alternative priority signals (for example, header- field or h2-update-frame) but there is no requirement to use a specific signal type. </ins> The value of SETTINGS_NO_RFC7540_PRIORITIES MUST be 0 or 1.  Any value other than 0 or 1 MUST be treated as a connection error (see
SETTINGS frame.  Detection of a change by a receiver MUST be treated as a connection error of type PROTOCOL_ERROR. <ins> The SETTINGS frame precedes any HTTP/2 priority signal sent from a client, so a server can determine if it needs to allocate any resource to signal handling before they arrive.  A server that receives SETTINGS_NO_RFC7540_PRIORITIES with value of 1 MUST ignore HTTP/2 priority signals. 2.1.1. </ins> Until the client receives the SETTINGS frame from the server, the client SHOULD send both the HTTP/2 priority signals and the signals of this prioritization scheme (see header-field and h2-update-frame).
signal that might be useful to nodes behind the server that the client is directly connected to. <del> The SETTINGS frame precedes any HTTP/2 priority signal sent from a client, so a server can determine if it needs to allocate any resource to signal handling before they arrive.  A server that receives SETTINGS_NO_RFC7540_PRIORITIES with value of 1 MUST ignore HTTP/2 priority signals. Where both endpoints disable RFC 7540 stream priority, the client is expected to send this scheme's priority signal.  Handling of omitted signals is described in parameters. </del> 3. The priority scheme defined by this document considers only the
The problems and insights set out above provided the motivation for deprecating RFC 7540 stream priority (see Section 5.3 of RFC7540). <del> The SETTINGS_DEPRECATE_RFC7540_PRIORITIES setting is defined by this </del> <ins> The SETTINGS_NO_RFC7540_PRIORITIES setting is defined by this </ins> document in order to allow endpoints to explicitly opt out of using HTTP/2 priority signals (see Section 5.3.2 of HTTP2).  Endpoints are expected to use an alternative, such as the scheme defined in this specification. <del> The value of SETTINGS_DEPRECATE_RFC7540_PRIORITIES MUST be 0 or 1. Any value other than 0 or 1 MUST be treated as a connection error (see Section 5.4.1 of HTTP2) of type PROTOCOL_ERROR. </del> <ins> The value of SETTINGS_NO_RFC7540_PRIORITIES MUST be 0 or 1.  Any value other than 0 or 1 MUST be treated as a connection error (see Section 5.4.1 of HTTP2) of type PROTOCOL_ERROR. </ins> Endpoints MUST send this SETTINGS parameter as part of the first SETTINGS frame.  A sender MUST NOT change the <del> SETTINGS_DEPRECATE_RFC7540_PRIORITIES parameter value after the first </del> <ins> SETTINGS_NO_RFC7540_PRIORITIES parameter value after the first </ins> SETTINGS frame.  Detection of a change by a receiver MUST be treated as a connection error of type PROTOCOL_ERROR.
client SHOULD send both the HTTP/2 priority signals and the signals of this prioritization scheme (see header-field and h2-update-frame). When the client receives the first SETTINGS frame that contains the <del> SETTINGS_DEPRECATE_RFC7540_PRIORITIES parameter with value of 1, it SHOULD stop sending the HTTP/2 priority signals.  If the value was 0 or if the settings parameter was absent, it SHOULD stop sending </del> <ins> SETTINGS_NO_RFC7540_PRIORITIES parameter with value of 1, it SHOULD stop sending the HTTP/2 priority signals.  If the value was 0 or if the settings parameter was absent, it SHOULD stop sending </ins> PRIORITY_UPDATE frames (h2-update-frame), but MAY continue sending the Priority header field (header-field), as it is an end-to-end signal that might be useful to nodes behind the server that the
The SETTINGS frame precedes any HTTP/2 priority signal sent from a client, so a server can determine if it needs to allocate any resource to signal handling before they arrive.  A server that <del> receives SETTINGS_DEPRECATE_RFC7540_PRIORITIES with value of 1 MUST ignore HTTP/2 priority signals. </del> <ins> receives SETTINGS_NO_RFC7540_PRIORITIES with value of 1 MUST ignore HTTP/2 priority signals. </ins> Where both endpoints disable RFC 7540 stream priority, the client is expected to send this scheme's priority signal.  Handling of omitted
Endpoints MUST send this SETTINGS parameter as part of the first SETTINGS frame.  A sender MUST NOT change the SETTINGS_NO_RFC7540_PRIORITIES parameter value after the first <del> SETTINGS frame.  Detection of a change by a receiver MUST be treated as a connection error of type PROTOCOL_ERROR. </del> <ins> SETTINGS frame.  Receivers that detect a change MAY treat it as a connection error of type PROTOCOL_ERROR. </ins> The SETTINGS frame precedes any HTTP/2 priority signal sent from a client, so a server can determine if it needs to allocate any
The default value of the incremental parameter is false ("0"). <del> A server might distribute the bandwidth of a connection between incremental responses that share the same urgency, hoping that providing those responses in parallel would be more helpful to the client than delivering the responses one by one. </del> <ins> If a client makes concurrent requests with the incremental parameter set to false, there is no benefit serving responses with the same urgency in parallel because the client is not going to process those responses incrementally.  Serving non-incremental responses with the same urgency one by one, in the order in which those requests were generated is considered to be the best strategy. </ins> If a client makes concurrent requests with the incremental parameter <del> set to false, there is no benefit serving responses in parallel because the client is not going to process those responses incrementally.  Serving non-incremental responses one by one, in the order in which those requests were generated is considered to be the best strategy. </del> <ins> set to true, serving requests with the same urgency in parallel might be beneficial.  Doing this distributes the connection bandwidth, meaning that responses take longer to complete.  Incremental delivery is most useful where multiple partial responses might provide some value to clients ahead of a complete response being available. </ins> The following example shows a request for a JPEG file with the urgency parameter set to "5" and the incremental parameter set to
<del> HTTP SEARCH Method </del> <ins> The HTTP QUERY Method </ins> draft-ietf-httpbis-safe-method-w-body-latest Abstract <del> This specification updates the definition and semantics of the HTTP SEARCH request method originally defined by RFC 5323. </del> <ins> This specification defines a new HTTP method, QUERY, as a safe, idempotent request method that can carry request content. </ins> Editorial Note
1. <del> This specification updates the HTTP SEARCH method originally defined in RFC5323. </del> <ins> This specification defines the HTTP QUERY request method as a means of making a safe, idempotent request that contains content. </ins> <del> Many existing HTTP-based applications use the HTTP GET and POST methods in various ways to implement the functionality provided by SEARCH. </del> <ins> Most often, this is desirable when the data conveyed in a request is too voluminous to be encoded into the request's URI.  For example, while this is an common and interoperable query: </ins> <del> Using a GET request with some combination of query parameters included within the request URI (as illustrated in the example below) is arguably the most common mechanism for implementing search in web applications.  With this approach, implementations are required to parse the request URI into distinct path (everything before the '?') and query elements (everything after the '?').  The path identifies the resource processing the query (in this case 'http://example.org/ feed') while the query identifies the specific parameters of the search operation. </del> <ins> if the query parameters extend to several kilobytes or more of data it may not be, because many implementations place limits on their size.  Often these limits are not known or discoverable ahead of time, because a request can pass through many uncoordinated systems. Additionally, expressing some data in the target URI is inefficient, because it needs to be encoded to be a valid URI. </ins> <del> A typical use of HTTP GET for requesting a search While there are definite advantages to using GET requests in this manner, the disadvantages should not be overlooked.  Specifically: </del> <ins> Encoding query parameters directly into the request URI also effectively casts every possible combination of query inputs as distinct resources.  Depending on the application, that may not be desirable. </ins> As an alternative to using GET, many implementations make use of the HTTP POST method to perform queries, as illustrated in the example