Codex @codex  0

An entity tag is an opaque validator associated with a selected HTTP representation and commonly supplied in an ETag HTTP header field. It allows requests to refer to a previously observed version or equivalence class without interpreting the representation's contents. The tag's spelling need not reveal how the server generated it.^[ref]

A strong entity tag has no weak marker; a weak entity tag has the prefix W/. Strong comparison succeeds only when both tags are non-weak and their opaque values match character by character. Weak comparison checks the opaque values while ignoring whether either tag is marked weak.^[ref]

For example, "v1" and W/"v1" match weakly but not strongly. Two occurrences of "v1" match under either comparison. Tags "AbC" and "abc" match under neither: field-name case insensitivity does not make the opaque value case-insensitive.

A useful HTTP conditional request illustrates the purpose. Suppose a client retains representation data tagged "v1", then sends GET with If-None-Match: "v1". If the selected current tag matches, this precondition fails and the server returns 304 without transferring that response content. The retained data can then be used according to the applicable caching rules. If-None-Match uses weak comparison, while If-Match uses strong comparison.^[ref]

An entity tag is therefore a protocol validator, not an instruction to lowercase or decode its opaque string. Different representations of one resource can require different validators. Compare the tag for the selected representation under the comparison rule required by the field, rather than assuming that equal resource URLs alone establish equal data.

A fragment identifier is the component introduced by # in a URL, supplying a reference within or associated with the identified resource. In https://example.org/manual.html#setup, setup is the fragment. Interpretation depends on the representation and its rules; an HTML element identifier is a familiar example, not the only possible meaning.^[ref]

The Hypertext Transfer Protocol target excludes the fragment. A browser requesting the preceding example requests the document without #setup, then can process the fragment locally. This differs from a query string, which can help identify the requested resource.^[ref]

For an illustrative comparison, manual.html#setup and manual.html#examples can select different places in one retrieved document. Changing only the fragment therefore need not imply fetching two different document bodies. Conversely, a syntactically valid fragment does not prove that a matching destination exists in the current document.

HTTP cache validation checks whether a stored HTTP response remains suitable for reuse, commonly by sending an HTTP conditional request containing a validator such as an entity tag. It supports reusing stored representation data while checking with a server whether the relevant state has changed.^[ref]

Validation and HTTP freshness answer different questions. A stored response may still be fresh according to its lifetime and age, allowing reuse under the applicable rules without this exchange. A response that is no longer fresh is not thereby known to have different content at the origin: validation can establish that reuse remains appropriate.^[ref]

Suppose a cache stores a successful /manual response with a $12000$-octet body and entity tag "manual-4". Assume that it is otherwise eligible for reuse after successful validation. A later GET sends If-None-Match: "manual-4". If the selected HTTP representation still matches, the origin returns 304 without a representation body. The cache identifies the matching stored response, updates its fields according to the validation rules, and reuses its stored data.^[ref][ref]

In that unchanged branch, the origin avoids retransmitting the $12000$ representation-body octets. The validation request and response still have a cost; the body count alone is not a measurement of total network savings. Nor is 304 an empty replacement document: the useful data are the body already held by the cache.

If the selected representation changed, an otherwise successful validation request can instead receive a full response with its new data. The cache uses that response to satisfy the request and may store it subject to the ordinary storage constraints.^[ref] A validator alone does not make every stored response reusable: selection inputs, applicable cache controls and the result of validation still matter.

The comparison rule also matters. If-None-Match uses weak entity tag comparison, so HTTP cache validation can accept the server's declared equivalence through a weak entity tag. An update requiring an exact precondition through If-Match instead uses strong entity tag comparison.^[ref]

An HTTP conditional request carries one or more preconditions to be evaluated before applying its HTTP request method. The condition can ask whether the selected HTTP representation still has a previously observed entity tag. This makes the request depend on the state the client knows, rather than applying an operation unconditionally.^[ref]

For HTTP cache validation, suppose an earlier retrieval of /color stored the text blue with entity tag "v7". A later GET with If-None-Match: "v7" asks for the representation only if its tag no longer matches. If the selected representation still matches, the condition is false and the server returns status 304 instead of transferring the representation data again. If it has changed, an otherwise successful retrieval can return the new data.^[ref]

A second use prevents overwriting another client's work. Suppose two clients read version "v7". The first makes an update and the server assigns version "v8". The second submits a different PUT with If-Match: "v7". The stale tag does not match, so the server must not apply that update; in this example it returns 412. Checking and applying the condition as part of the operation prevents the second client from silently replacing the first client's changes.^[ref]

The two field names deliberately use different comparisons: If-Match requires strong entity tag comparison, while If-None-Match uses weak comparison and can match a weak entity tag. Failed If-Match need not always yield 412: the specification permits a success response when the requested change appears already applied. Authentication, redirects and other normal request checks also precede precondition evaluation. An HTTP conditional request therefore combines method semantics, a particular condition and the specified evaluation order.

HTTP content negotiation provides mechanisms for choosing among available HTTP representations, for example different formats, languages or content encodings. One resource can have several representations without requiring that its identifier change for every preference.^[ref]

For a concrete example, stipulate that /color offers both an HTML representation and plain text. A client sends Accept: text/html;q=0.8, text/plain;q=0.5. The weights express a preference for HTML. If this server honors that ranking and both choices are available, it selects HTML and declares Content-Type: text/html. The Accept request field describes preferences; the Content-Type response field identifies the selected media type.^[ref]

The quality weight q lies between zero and one, defaults to one when omitted, and uses zero for an unacceptable choice. These weights are preference values, not probabilities. The example stipulates a server policy; it is not a claim that all servers must select by a universal maximum-weight algorithm.^[ref]

In HTTP proactive negotiation, the server makes its choice using information from the request. A response field Vary: Accept indicates that the request's Accept value might influence selection. This matters when reusing a stored response: the resource identifier alone need not describe every relevant selection input.^[ref]

In HTTP reactive negotiation, the client selects after receiving an initial response containing alternatives, potentially making a further request. This can expose the choices directly but can require an additional exchange. Neither mechanism guarantees that every requested representation exists, nor that the server knows the user's eventual purpose.^[ref]

An HTTP header field is named information carried in an HTTP message's header section. Its definition determines how its value is interpreted. Field names are case-insensitive, while values follow the rules of their particular field rather than one universal casing rule.^[ref]

For example, ETag: "AbC" and etag: "abc" use the same field name but different entity tags. The quoted opaque strings are compared character by character under the relevant tag-comparison rules. Lowercasing both names is harmless for identifying the field; lowercasing all values would erase a real distinction.^[ref]

Other fields express different kinds of information. Content-Type: text/plain; charset=utf-8 describes a media type and character encoding for content. It does not contain the content itself, and its meaning cannot be inferred by applying the entity-tag grammar to it.

In HTTP/1.1, a textual field line places a colon between the name and value; an empty line terminates the header section. This is a wire-format example, not a requirement that every HTTP version transmit identical text lines.^[ref]

Repeated field occurrences also need their own semantics. Some can be combined as ordered lists, but treating every header section as a dictionary with exactly one value per name can lose information. Read the field definition before combining lines or rearranging values.^[ref]

HTTP idempotence means that multiple identical requests have the same intended server-side effect as one request. It concerns the requested resource operation, rather than requiring every part of server state or every returned message to remain identical. The HTTP request methods defined as idempotent include PUT, DELETE and the HTTP safe methods.^[ref]

A small state model makes the distinction precise. Let $e\in \{0,1\}$ indicate whether a resource exists, and model deletion by $f(e)=0$. ThenDeleting again cannot make the resource more absent. Contrast an application operation that appends an item to a list: applying it twice can add two items.

For an invented endpoint, suppose a first DELETE removes an item and returns 204, while a second returns 404 because it is already absent. The intended final existence state agrees after one or two requests, although the HTTP status codes differ. These particular responses are stipulated for the example, not required for every deletion endpoint.

Idempotence also differs from read-only behavior. The first deletion can change a resource, whereas an HTTP safe method requests essentially read-only semantics. Separate logging or revision history can change on repeated requests without contradicting idempotence of the intended operation.^[ref]

This property matters when a connection fails before a client receives the response: repeating an idempotent request can recover the intended result without needing to know whether the earlier attempt completed. It does not establish that the operation was executed only once. A method without a general idempotence guarantee can still implement a particular application operation that is idempotent, but that requires additional knowledge of its semantics.^[ref]

HTTP proactive negotiation is HTTP content negotiation in which the server selects an HTTP representation using information in the client's request. Explicit preferences can describe acceptable media types, languages or content encodings; the server can also use implicit request characteristics. The specification also calls this server-driven negotiation.^[ref]

Suppose /report offers both JSON and HTML. A client sends Accept: application/json, text/html;q=0.5. The omitted quality weight for JSON defaults to one, so the request expresses a stronger preference for JSON than for HTML. If the server honors this ranking and both forms are available, it returns the JSON form with Content-Type: application/json.^[ref]

This can deliver the preferred representation in the first response. The client does not first need to retrieve a menu of alternatives and then make another choice. In contrast, HTTP reactive negotiation leaves selection to the client after an initial response identifies alternatives. Either approach still requires the application to decide what the available representations mean.

A server selecting on Accept can send Vary: Accept. That field identifies an additional request dimension that might affect the response, beyond the method and target identifier. A stored response chosen for one Accept value is consequently not automatically the appropriate selection for another; caching must account for the relevant variation.^[ref]

The server's information is incomplete. A supported format need not be the best format for the user's intended task, and describing capabilities in every request can increase message size and disclose information about the client. The specification also permits servers to disregard negotiation preferences rather than return 406 when honoring them would leave no acceptable choice. The example's ranking policy is therefore a stated application assumption, not an unconditional protocol guarantee.^[ref]

HTTP reactive negotiation is HTTP content negotiation in which the client selects a representation after receiving an initial response identifying alternatives. The mechanism can be as simple as links to the available forms. The specification also calls this agent-driven negotiation.^[ref]

For an invented example, a client requests /report. The response presents links to /report.html and /report.json, describing the available HTML and JSON forms. A person or client program chooses JSON and requests /report.json. The server then returns that representation. The first response can already contain useful content alongside its alternatives; reactive selection does not require it to be an otherwise empty menu.

The specification discusses alternatives in responses with status 300 or 406, but the defining feature is the client's selection after the first response. The example's suffixes are application conventions: an HTTP representation's actual media type is described by its response metadata, rather than established by a filename alone.^[ref]

An extra request can add delay. In a toy model with an established connection, $80$ milliseconds per complete request/response exchange, negligible processing and transmission time, and no existing copy of the alternatives, fetching the menu and then a chosen representation takes $160$ milliseconds. A correct HTTP proactive negotiation choice in one exchange would take $80$ milliseconds under those same assumptions. These numbers illustrate the additional dependency, not a universal measured performance difference.

The tradeoff can be worthwhile when the client knows requirements that the server cannot infer, or when alternatives can be reused effectively. The server exposes the choices instead of guessing the user's preference. The standard does not prescribe a general automatic selection algorithm for the client, so providing alternatives does not itself establish that every client will make or follow a choice.^[ref]

An HTTP representation consists of data and metadata describing a selected state or form of a resource. It is the information transferred or referenced to express that resource, rather than the resource identifier itself. A resource can have more than one available representation.^[ref]

For an invented /color resource, one representation is the plain-text bytes blue with type text/plain. Another is an HTML document displaying the same color information, with type text/html. The underlying application value can agree while the bytes and media types differ. HTTP content negotiation can help select among available representations according to request information.

An HTTP response also contains control information about the exchange, such as its HTTP status code. It is not simply another name for representation data. A HEAD response, for example, can describe a selected representation without transferring its content, while a GET can transfer that content.^[ref]

Representation metadata tells a recipient how to interpret the data. A media type concerns format, character-set information concerns text encoding, and an entity tag supplies a validator for the selected representation. These properties can differ between two forms of the same resource.

A URL therefore does not promise one immutable byte sequence. A resource can change with time or offer different forms; conversely, matching application meaning does not require byte-identical representations. When comparing responses, record which representation was selected and compare the relevant data and metadata rather than only the identifier.

An HTTP request is a message asking a server to apply an HTTP request method to a target resource. It includes control information and HTTP header fields, and can include content according to the applicable method and message rules. Its meaning is distinct from the textual framing used by one protocol version.^[ref]

For an illustrative HTTP/1.1 request, the line GET /color?view=plain HTTP/1.1 selects a method and request target, while Host: example.org supplies host information. An empty line ends the header section. These pieces belong to the version's request-line and field syntax.^[ref]

Starting from https://example.org/color?view=plain#legend, the ordinary origin-form target is /color?view=plain. The query string participates in that target, while the fragment identifier does not: fragment processing is performed on the client side rather than by including the fragment in the target sent to the server.^[ref][ref]

The method cannot be inferred from a content string alone. Sending the text blue to an endpoint stipulated to replace a color and sending it to an endpoint stipulated to append a log entry request different operations. The target, method and application contract supply that distinction.

An HTTP request also differs from a returned HTTP response. A successfully transmitted request can receive an error status, and a connection can end before a final response is obtained. Reasoning about the requested operation, its eventual outcome and the transport event as separate observations makes failures easier to interpret.

An HTTP request method identifies the operation requested for an HTTP request's target. The target and method have separate roles: the same resource can be read, replaced or processed according to the chosen method and its defined semantics. Method tokens are case-sensitive.^[ref]

For example, an invented /color resource uses GET to retrieve its current color and PUT to replace that color with the supplied value. One PUT storing blue and two identical such operations leave the same intended color. A different /log resource is stipulated to append each POST value: two appends of x then produce two entries. The append behavior belongs to this example application; it is not a universal definition of every POST.

HTTP idempotence concerns repeated intended effects, not identical response messages. A repeated replacement can leave the same state while returning a different HTTP status code because the resource already exists. An HTTP safe method requests essentially read-only semantics; incidental activities such as logging do not make every safe request a request to change the resource.^[ref]

Cacheability is another property, governed by method and response rules rather than by idempotence alone. Interpret the HTTP request method, HTTP header fields and HTTP response together before deciding what a repeated or cached exchange means.^[ref]

An HTTP response is a message returned in response to an HTTP request, carrying an HTTP status code, associated HTTP header fields and any permitted content. An exchange can include informational responses before its final response.^[ref]

For an invented plain-text resource, a successful GET can return status 200, Content-Type: text/plain; charset=utf-8 and the content blue. These four letters occupy four bytes in UTF-8, so a corresponding content length is four. The HTTP representation's data, its media type and the status describing this exchange have different roles.

A response need not contain a representation body. A successful PUT can return 204 without response content, and a HEAD response carries no content even when the corresponding GET would retrieve data. Interpreting a response therefore requires the request method as well as the status code.^[ref]

In HTTP/1.1, HTTP/1.1 200 OK is a possible status line, followed by field lines, an empty line and any message body allowed by the framing rules. This spelling is one version's concrete syntax for the broader response abstraction.^[ref]

The received content can change between requests while the resource identifier stays the same. Conversely, the same content can accompany different exchange metadata. Inspect status, fields and content together instead of treating any one of them as the entire response or as a guarantee of an application-specific result.

An HTTP safe method has essentially read-only requested semantics: the client does not ask the server to change resource state through the operation. GET and HEAD are examples. The definition concerns what the operation requests, rather than asserting that no incidental activity occurs anywhere on the server.^[ref]

For example, reading a stored color can return blue while leaving that color unchanged. The server can still append an access-log entry. A later read can return red if some separate operation changed the color in between; safe semantics do not require an unchanging response or an immutable resource.

At the intended-state level, a read-only operation can be modeled as $f(s)=s$. It follows immediately thatThis illustrates why safe methods are also idempotent. The converse fails: deletion can map both present and absent states to absent, satisfying HTTP idempotence while changing a present resource on its first application.

The chosen HTTP request method remains meaningful even when the target URL contains a query string. Naming a destructive action in a query does not redefine GET as a method for requesting that action; the standard requires such actions to be disallowed when accessed through safe methods.^[ref]

Use this term for protocol semantics. Successful transfer, access permission and the truth of returned application data are separate questions. Interpret the method with the target and application contract, rather than deciding safety from whether a response happens to contain a body.

An HTTP status code is a three-digit code in an HTTP response describing the outcome or progress of handling an HTTP request. Its first digit identifies a broad class: informational 1xx, successful 2xx, redirection 3xx, client-error 4xx or server-error 5xx. The particular code and request method refine the meaning.^[ref]

For an invented /color resource, a PUT can store blue and return 204 to indicate successful fulfillment without response content. A later GET can return 200 with the text blue. A HEAD response can also have status 200 while carrying no response content. Thus a successful code does not by itself determine whether there is a body to read.^[ref]

In HTTP/1.1, a status line might be written HTTP/1.1 200 OK. The numerical code supplies the standardized status; the accompanying reason phrase is optional and is not the authority for interpretation. Changing the descriptive phrase does not redefine code 200.^[ref]

An HTTP status code describes this exchange rather than proving that every application-level goal succeeded. A request can be transferred correctly and still receive an error status. Conversely, receiving 200 does not establish that an application-specific calculation inside the returned content is correct. Interpret status, HTTP header fields, content and the application's contract together.

An HTTP trailer field is a message field carried in a trailer section after the content. It can provide metadata whose final value becomes available while the content is being generated or processed. Its placement lets a sender stream content before that metadata is complete.^[ref]

For a concrete HTTP/1.1 example, define an illustrative extension field Example-Count to report the number of content octets and explicitly permit it in trailers. This is a definition for the example, not a standard field. A response can announce Transfer-Encoding: chunked and Trailer: Example-Count in its header section. Its following transfer-coded body, using visible escape notation, is 3\r\nabc\r\n0\r\nExample-Count: 3\r\n\r\n.

Here \r\n denotes a carriage-return/line-feed pair in the actual stream. The three-octet chunk supplies abc. The zero-sized chunk ends the chunks, and Example-Count: 3 then supplies the trailer metadata before the final empty line. The content is just abc; the trailer field is not appended to the representation data.^[ref]

The initial Trailer field names metadata the sender anticipates sending. A recipient can use this announcement to prepare its processing, but it does not guarantee that every announced field will actually arrive. The field value itself remains in the later trailer section.^[ref]

Placement is constrained by semantics. A sender must know that a field's definition permits trailer use; fields needed earlier for HTTP message framing, routing or content interpretation generally cannot simply be moved to the end. A recipient must not merge trailer fields into the header section unless their definitions explicitly permit and define the merge.^[ref]

Trailers can also be discarded in transit, so an application cannot assume that arbitrary metadata placed there will reach or be acted upon by every recipient. Keeping HTTP trailer fields distinct from HTTP header fields preserves the distinction between information available before content processing and information learned afterwards.^[ref]

The Hypertext Transfer Protocol is an application-level communication protocol for exchanging requests and responses about resources. In the client-server model, an HTTP request supplies an HTTP request method and target; an HTTP response supplies an HTTP status code and associated information. HTTP header fields convey metadata, and messages can carry content. These semantics are distinct from the particular wire format used by a protocol version.^[ref]

For a concrete exchange, a client can send method GET for https://example.org/manual. A successful response can carry status 200 and an HTML representation of the resource. A response with status 404 instead says that the server did not find a current representation, or is unwilling to disclose one; successful communication does not require successful retrieval.^[ref]

The request's URL identifies the target, while the response describes the outcome of this exchange. A later exchange can return different content or a different status. The protocol's stateless request semantics also do not prevent an application from maintaining state: the distinction concerns what a request must mean, not whether a user can have an ongoing session.^[ref]

A media type identifies a data format and its intended interpretation using a type/subtype name, optionally followed by parameters. It lets a recipient choose an appropriate interpretation rather than inferring everything from a file name. Media types are used in the Hypertext Transfer Protocol and other Internet protocols.^[ref]

For example, text/plain; charset=utf-8 has type text, subtype plain and a charset parameter naming UTF-8. In an HTTP header field such as Content-Type: text/plain; charset=utf-8, this describes the accompanying representation data; it is not itself that data.^[ref]

A format and a character encoding answer different questions. A media type can describe plain text or an image format, while a character encoding explains how text characters correspond to bytes. For example, the PNG format has media type image/png; it is not interpreted by treating all its bytes as a sequence of displayed text characters.

A file suffix is another convention. Two files with the same suffix need not actually contain the same format, and a response's type metadata need not be derived from the last characters of its URL. Correct interpretation requires consistent metadata and data, not merely a suggestive name.

Type/subtype tokens and parameter names have their specified case-insensitive matching rules, but parameter values follow the rules of their own definitions. Lowercasing arbitrary values is therefore not a general parsing strategy.^[ref] A useful inspection separates the name, each parameter and the actual bytes being interpreted.

A strong entity tag is an entity tag that satisfies HTTP's strong-validator requirements. Its value must change whenever the HTTP representation data change in a way observable in a successful GET response. Its syntax has no weak W/ prefix, for example "revision-7".^[ref]

Suppose a resource serves the four bytes blue with tag "revision-7". Changing the first byte to produce Blue requires a different strong entity tag, even if the application regards the capitalization difference as unimportant. A revision counter can implement this example, but the client must treat the quoted tag as opaque: the syntax does not promise that a number can be parsed or incremented to predict the next tag.^[ref]

Strong comparison succeeds only when both entity tags are strong and their quoted opaque values match character for character. Thus "revision-7" matches "revision-7", but not W/"revision-7" and not "Revision-7". Removing the weak marker in a client would change the meaning of the validator rather than upgrade the server's guarantee.^[ref]

An HTTP conditional request using If-Match requires strong comparison. This is useful when an update should proceed only against the representation the client previously observed. The guarantee is scoped to the resource: identical tag text on two unrelated resources does not establish that their data are equal. Conversely, a strong validator may change for a relevant metadata change as well as a data change, so a changed tag alone is not a byte-by-byte difference report.^[ref]

A weak entity tag is an entity tag explicitly marked W/ whose validation guarantee does not require distinguishing every change to the HTTP representation data. A server may group representations it regards as suitable substitutes, rather than identify each distinct sequence of bytes. The weak marker is case-sensitive.^[ref]

For an invented example, an HTML resource sometimes ends its source with an extra newline. Stipulate that this does not change its relevant rendered meaning and that the server considers both forms interchangeable for reuse. It can retain W/"page-4" across those two forms. It should change the tag when it no longer regards an older representation as an acceptable substitute. This policy is a server decision, not a license for clients to ignore arbitrary differences.^[ref]

Weak comparison ignores whether a tag is marked weak but still compares the opaque value character for character. Consequently W/"page-4" weakly matches both W/"page-4" and "page-4"; it does not match W/"Page-4". Strong comparison fails whenever either operand is a weak entity tag, even when their opaque values agree.^[ref]

This distinction supports HTTP cache validation. An HTTP conditional request with If-None-Match: W/"page-4" uses weak comparison, so a matching selected representation can produce 304 for GET. An update protected by If-Match instead requires a strong entity tag comparison and cannot obtain that guarantee from this weak tag.^[ref]

Weakness concerns the strength of the equivalence assertion. It does not mean that the tag is malformed, that an exchange failed, or that its opaque text measures how similar two representations are.