jiebi/CodeConvo huggingface dataset:
provides a list of representations for the user agent to choose from, and "request payload" negotiation, where the user agent selects the representation for a future request based upon the server's stated <del> preferences in past responses.  Other patterns of content negotiation include "conditional content", where the representation consists of multiple parts that are selectively rendered based on user agent parameters, "active content", where the representation contains a script that makes additional (more specific) requests based on the user agent characteristics, and "Transparent Content Negotiation" (RFC2295), where content selection is performed by an intermediary. These patterns are not mutually exclusive, and each has trade-offs in </del> <ins> preferences in past responses. Other patterns of content negotiation include "conditional content", where the representation consists of multiple parts that are selectively rendered based on user agent parameters, "active content", where the representation contains a script that makes additional (more specific) requests based on the user agent characteristics, and "Transparent Content Negotiation" (RFC2295), where content selection is performed by an intermediary.  These patterns are not mutually exclusive, and each has trade-offs in </ins> applicability and practicality. Note that, in all cases, HTTP is not aware of the resource semantics.
decimal point.  User configuration of these values ought to be limited in the same fashion. <del> 12.1.1.3. </del> <ins> 12.4.3. </ins> Most of these header fields, where indicated, define a wildcard value <del> ("*") to select unspecified values.  If no wildcard is present, all values not explicitly mentioned in the field are considered "not acceptable" to the client. </del> <ins> ("*") to select unspecified values.  If no wildcard is present, values that are not explicitly mentioned in the field are considered unacceptable, except for within where it means the variance is unlimited. 12.5. </ins> <del> 12.1.2. </del> <ins> 12.5.1. </ins> The "Accept" header field can be used by user agents to specify their preferences regarding response media types.  For example, Accept
does not provide such control to the user MUST NOT send an Accept- Language header field. <del> 12.2. With (a.k.a., ), selection of the best response representation (regardless of the status code) is performed by the user agent after receiving an initial response from the origin server that contains a list of resources for alternative representations.  If the user agent is not satisfied by the initial response representation, it can perform a GET request on one or more of the alternative resources, selected based on metadata included in the list, to obtain a different form of representation for that response.  Selection of alternatives might be performed automatically by the user agent or manually by the user selecting from a generated (possibly hypertext) menu. Note that the above refers to representations of the response, in general, not representations of the resource.  The alternative representations are only considered representations of the target resource if the response in which those alternatives are provided has the semantics of being a representation of the target resource (e.g., a response to a GET request) or has the semantics of providing links to alternative representations for the target resource (e.g., a response to a GET request). A server might choose not to send an initial representation, other than the list of alternatives, and thereby indicate that reactive negotiation by the user agent is preferred.  For example, the alternatives listed in responses with the and status codes include information about the available representations so that the user or user agent can react by making a selection. Reactive negotiation is advantageous when the response would vary over commonly used dimensions (such as type, language, or encoding), when the origin server is unable to determine a user agent's capabilities from examining the request, and generally when public caches are used to distribute server load and reduce network usage. Reactive negotiation suffers from the disadvantages of transmitting a list of alternatives to the user agent, which degrades user-perceived latency if transmitted in the header section, and needing a second request to obtain an alternate representation.  Furthermore, this specification does not define a mechanism for supporting automatic selection, though it does not prevent such a mechanism from being developed as an extension. 12.2.1. </del> <ins> 12.5.5. </ins> The "Vary" header field in a response describes what parts of a request message, aside from the method and target URI, might
it considers the variance less significant than the performance cost of Vary's impact on caching. <del> 12.3. When content negotiation preferences are sent in a server's response, the listed preferences are called because they intend to influence selection of an appropriate payload for subsequent requests to that resource.  For example, the (field.accept) and (field.accept-encoding) header fields can be sent in a response to indicate preferred media types and content codings for subsequent requests to that resource. Similarly, RFC5789 defines the "Accept-Patch" response header field which allows discovery of which content types are accepted in PATCH requests. </del> 13. A conditional request is an HTTP request with one or more request
The status codes listed below are defined in this specification.  The reason phrases listed here are only recommendations -- they can be <del> replaced by local equivalents without affecting the protocol. </del> <ins> replaced by local equivalents or left out altogether without affecting the protocol. </ins> Responses with status codes that are defined as heuristically cacheable (e.g., 200, 203, 204, 206, 300, 301, 308, 404, 405, 410,
10.1. <del> A client sends request header fields to provide more information about the request context, make the request conditional based on the target resource state, suggest preferred formats for the response, supply authentication credentials, or modify the expected request processing.  These fields act as request modifiers, similar to the parameters on a programming language method invocation. </del> The request header fields below provide additional information about the request context, including information about the user, user agent, and resource behind the request.
The status code indicates that the server did not receive a complete <del> request message within the time that it was prepared to wait.  If the client has an outstanding request in transit, the client MAY repeat that request on a new connection. </del> <ins> request message within the time that it was prepared to wait. If the client has an outstanding request in transit, it MAY repeat that request.  If the current connection is not usable (e.g., as it would be in HTTP/1.1, because request delimitation is lost), a new connection will be used. </ins> 15.5.10.
A server MAY ignore the Range header field.  However, origin servers and intermediate caches ought to support byte ranges when possible, since they support efficient recovery from partially failed transfers <del> and partial retrieval of large representations.  A server MUST ignore a Range header field received with a request method other than GET. </del> <ins> and partial retrieval of large representations. A server MUST ignore a Range header field received with a request method which is unrecognized or for which range handling is not defined.  For this specification, is the only method for which range handling is defined. </ins> An origin server MUST ignore a Range header field that contains a range unit it does not understand.  A proxy MAY discard a Range
9.3.2. The HEAD method is identical to GET except that the server MUST NOT <del> send payload data in the response (i.e., the response terminates at the end of the header section).  The server SHOULD send the same header fields in response to a HEAD request as it would have sent if the request had been a GET, except that header fields that describe message body encoding or transmission (e.g., </del> <ins> send payload data in the response and the response always terminates at the end of the header section.  HEAD is used to obtain metadata about the without transferring its representation data, often for the sake of testing hypertext links or finding recent modifications. The server SHOULD send the same header fields in response to a HEAD request as it would have sent if the request method had been GET. However, a server MAY omit header fields for which a value is determined only while generating the payload data.  For example, some servers buffer a dynamic response to GET until a minimum amount of data is generated so that they can more efficiently delimit small responses or make late decisions with regard to content selection. Such a response to GET might contain </ins> <del> ) MAY be omitted. HEAD is used to obtain metadata about the </del> <ins> and </ins> <del> without transferring the representation data.  It is often used to test hypertext links for validity, accessibility, and recent modification. </del> <ins> fields, for example, that are not generated within a HEAD response. These minor inconsistencies are considered preferable to generating and discarding the payload data for a HEAD request, since HEAD is usually requested for the sake of efficiency. </ins> A payload within a HEAD request message has no defined semantics; sending payload data in a HEAD request might cause some existing
effort attempt to remove the information from volatile storage as promptly as possible after forwarding it. <del> This directive is NOT a reliable or sufficient mechanism for ensuring privacy.  In particular, malicious or compromised caches might not recognize or obey this directive, and communications networks might be vulnerable to eavesdropping. </del> <ins> This directive is a reliable or sufficient mechanism for ensuring privacy.  In particular, malicious or compromised caches might not recognize or obey this directive, and communications networks might be vulnerable to eavesdropping. </ins> Note that if a request containing this directive is satisfied from a cache, the no-store request directive does not apply to the already
effort attempt to remove the information from volatile storage as promptly as possible after forwarding it. <del> This directive is NOT a reliable or sufficient mechanism for ensuring privacy.  In particular, malicious or compromised caches might not recognize or obey this directive, and communications networks might be vulnerable to eavesdropping. </del> <ins> This directive is a reliable or sufficient mechanism for ensuring privacy.  In particular, malicious or compromised caches might not recognize or obey this directive, and communications networks might be vulnerable to eavesdropping. </ins> 5.2.2.5.
member, as described in trailer.fields. Additionally, specific HTTP versions can use it to indicate the <del> transfer codings the client is willing to accept in the response. </del> <ins> transfer codings the client is willing to accept in the response.  As of publication, only HTTP/1.1 uses transfer codings (see transfer.codings). </ins> The TE field value consists of a list of tokens, each allowing for optional parameters (except for the special case "trailers").
Wide Web since its introduction in 1990.  It began as a trivial mechanism for low-latency requests, with a single method (GET) to request transfer of a presumed hypertext document identified by a <del> given pathname.  This original protocol is now referred to as HTTP/0.9 (see HTTP09). As the Web grew, HTTP was extended to enclose requests and responses within messages, transfer arbitrary data formats using MIME-like media types, and route requests through intermediaries, eventually being defined as HTTP/1.0 RFC1945. </del> <ins> given pathname.  As the Web grew, HTTP was extended to enclose requests and responses within messages, transfer arbitrary data formats using MIME-like media types, and route requests through intermediaries.  These protocols were eventually defined as HTTP/0.9 and HTTP/1.0 (see RFC1945). </ins> HTTP/1.1 was designed to refine the protocol's features while retaining compatibility with the existing text-based messaging
subtypes of that type.  The media-range can include media type parameters that are applicable to that range. <del> Each media-range might be followed by zero or more applicable media type parameters (e.g., </del> <ins> Each media-range might be followed by optional applicable media type parameters (e.g., ), followed by an optional "q" parameter for indicating a relative weight (quality.values). </ins> <del> ), an optional "q" parameter for indicating a relative weight (quality.values), and then zero or more extension parameters.  The "q" parameter is necessary if any extensions (accept-ext) are present, since it acts as a separator between the two parameter sets. </del> <ins> This specification does not define "accept parameters" following the special "q" parameter, as was done in earlier editions.  Senders using weights SHOULD send "q" last (after all media-range parameters).  Recipients SHOULD process any parameter named "q" as weight, regardless of parameter ordering. </ins> The example
The must-revalidate directive is necessary to support reliable operation for certain protocol features.  In all circumstances a <del> cache MUST obey the must-revalidate directive; in particular, if a cache is disconnected, the cache MUST generate a </del> <ins> cache MUST NOT ignore the must-revalidate directive; in particular, if a cache is disconnected, the cache MUST generate an error response rather than reuse the stale response.  The generated status code SHOULD be </ins> <del> response rather than reuse the stale response. </del> <ins> unless another error status code is more applicable. </ins> The must-revalidate directive ought to be used by servers if and only if failure to validate a request on the representation could cause
MUST NOT attempt to recombine it with a stored representation.  A proxy that receives such a message SHOULD forward it downstream. <ins> A server MUST ignore a Content-Range header field received in a request with a method for which Content-Range support is not defined. No request method in this specification is defined to support Content-Range in a request. </ins> For byte ranges, a sender SHOULD indicate the complete length of the representation from which the range has been extracted, unless the complete length is unknown or difficult to determine.  An asterisk
the namespace for HTTP field names. Any party can request registration of a HTTP field.  See <del> considerations.for.new.field.values for considerations to take into account when creating a new HTTP field. </del> <ins> considerations.for.new.fields for considerations to take into account when creating a new HTTP field. </ins> The "Hypertext Transfer Protocol (HTTP) Field Name Registry" is located at <https://www.iana.org/assignments/http-fields/>.
16.3.2. <ins> HTTP header and trailer fields are a widely-used extension point for the protocol.  While they can be (and often are) used in an ad hoc fashion, fields that are widely used need to be more carefully documented, to ensure interoperability. In particular, authors of specifications defining new fields are advised to consider and, where appropriate, document the following aspects: Request header fields have additional considerations that need to be documented if the default behaviour is not appropriate: 16.3.2.1. </ins> Authors of specifications defining new fields are advised to choose a short but descriptive field name.  Short names avoid needless data transmission; descriptive names avoid confusion and "squatting" on
To that end, limited-use fields (such as a header confined to a single application or use case) are encouraged to use a name that <del> includes its name (or an abbreviation) as a prefix; for example, if </del> <ins> includes that use (or an abbreviation) as a prefix; for example, if </ins> the Foo Application needs a Description field, it might use "Foo- Desc"; "Description" is too generic, and "Foo-Description" is needlessly long.
prefixes are only an aid to recognizing the purpose of a field, and do not trigger automatic processing. <del> 16.3.3. </del> <ins> 16.3.2.2. A major task in the definition of a new HTTP field is the specification of the field value syntax: what senders should generate, and how recipients should infer semantics from what is received. Authors are encouraged (but not required) to use either the ABNF rules in this specification or those in RFCSTRF to define the syntax of new field values. Authors are advised to carefully consider how the combination of multiple field lines will impact them (see field-order).  Because senders might send erroneously send multiple values, and both intermediaries and HTTP libraries can perform combination automatically, this applies to all field values -- even when only a single value is anticipated. Therefore, authors are advised to either delimit values that contain commas (e.g., with the rule; see quoted.strings, or the String data type in RFCSTRF), or encode or escape them.  This ensures that commas in the payload of the field value are not confused with those used to delimit list values. For example, the field value only allows commas inside quoted strings, and so can be reliably parsed, even when multiple values are present.  The field value provides a counter-example that should not be emulated: because URIs can include commas, it is not possible to reliably distinguish between a single value that includes a comma from two values. </ins> <del> Authors of specifications defining new fields are advised to consider documenting: </del> <ins> Authors of fields with a singleton value (see field-values) are additionally advised to document how to treat messages where the multiple members are present (a sensible default would be to ignore the field, but this might not always be the right choice). </ins> 16.4.
15.5.20. <ins> The 421 (Misdirected Request) status code indicates that the request was directed at a server that is unable or unwilling to produce an authoritative response for the target URI.  A 421 is sent when an origin server (or gateway acting on behalf of the origin server) rejects a target URI that does not match an for which the server has been configured (origin) or does not match the connection context over which the request was received (routing.reject). A client that receives a 421 (Misdirected Request) response MAY retry the request, whether or not the request method is idempotent, over a different connection, such as a fresh connection specific to the target resource's origin, or via an alternative service RFC7838. A proxy MUST NOT generate a 421 response. A 421 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see heuristic.freshness). 15.5.21. </ins> The 422 (Unprocessable Payload) status code indicates that the server understands the content type of the request payload (hence a
15.5.20. <ins> The 421 (Misdirected Request) status code indicates that the request was directed at a server that is unable or unwilling to produce an authoritative response for the target URI.  A 421 is sent when an origin server (or gateway acting on behalf of the origin server) rejects a target URI that does not match an for which the server has been configured (origin) or does not match the connection context over which the request was received (routing.reject). A client that receives a 421 (Misdirected Request) response MAY retry the request, whether or not the request method is idempotent, over a different connection, such as a fresh connection specific to the target resource's origin, or via an alternative service RFC7838. A proxy MUST NOT generate a 421 response. 15.5.21. </ins> The 422 (Unprocessable Payload) status code indicates that the server understands the content type of the request payload (hence a
The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information <del> systems.  This document defines the semantics shared by all versions of HTTP, including its architecture, terminology, core protocol elements, and extensibility mechanisms, along with the "http" and </del> <ins> systems.  This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions.  In this definition are core protocol elements, extensibility mechanisms, and the "http" and </ins> "https" Uniform Resource Identifier (URI) schemes. This document obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC
that controls its message storage, retrieval, and deletion.  A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent requests.  Any <del> client or server MAY employ a cache, though a cache cannot be used by a server while it is acting as a tunnel. </del> <ins> client or server MAY employ a cache, though a cache cannot be used while acting as a tunnel. </ins> The effect of a cache is that the request/response chain is shortened if one of the participants along the chain has a cached response
3.4. <ins> A response might transfer only a partial representation if the connection closed prematurely or if the request used one or more Range specifiers (field.range).  After several such transfers, a cache might have received several ranges of the same representation. A cache MAY combine these ranges into a single stored response, and reuse that response to satisfy later requests, if they all share the same strong validator and the cache complies with the client requirements in combining.byte.ranges. When combining the new response with one or more stored responses, a cache MUST update the stored response header fields using the header fields provided in the new response, as per update. 3.5. </ins> A shared cache MUST NOT use a cached response to a request with an header field (field.authorization) to satisfy any subsequent request
public (cache-response-directive.public), and s-maxage (cache- response-directive.s-maxage). <del> 3.5. A response might transfer only a partial representation if the connection closed prematurely or if the request used one or more Range specifiers (field.range).  After several such transfers, a cache might have received several ranges of the same representation. A cache MAY combine these ranges into a single stored response, and reuse that response to satisfy later requests, if they all share the same strong validator and the cache complies with the client requirements in combining.byte.ranges. When combining the new response with one or more stored responses, a cache MUST update the stored response header fields using the header fields provided in the new response, as per update. </del> 4. When presented with a request, a cache MUST NOT reuse a stored
RFC3040 (also commonly known as a <del> RFC1919 or ) differs from an HTTP proxy because it is not chosen by the client. Instead, an interception proxy filters or redirects outgoing TCP port 80 packets (and occasionally other common port traffic). </del> <ins> RFC1919) differs from an HTTP proxy because it is not chosen by the client.  Instead, an interception proxy filters or redirects outgoing TCP port 80 packets (and occasionally other common port traffic). </ins> Interception proxies are commonly found on public network access points, as a means of enforcing account subscription prior to allowing use of non-local Internet services, and within corporate