Computer network

A computer network connects computing devices so they can exchange data using communication protocols. Packet switching shares communication links among many exchanges; routers forward network packets between connected networks. The arrangement of machines and links need not coincide with the arrangement of administrative control.

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.

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]

An HTTP cache key is the information an HTTP cache uses to choose a stored response. The standard's minimum basis comprises the request method and target URI, while additional request information can distinguish negotiated responses or partition storage. Common caches that store only GET responses can use the URI alone for that minimum basis.^[ref]

For an own example, suppose a cache holds both JSON and HTML responses for GET /report, each with Vary: Accept. Their explanatory selection inputs are (GET, /report, Accept=application/json) and (GET, /report, Accept=text/html). The target and method agree, but the nominated field distinguishes the variants. Another matching request for JSON must not receive the HTML entry merely because its target is also /report.^[ref]

A request for /report?page=2 also has a different target from /report. Sharing a path prefix is not enough to identify a stored response. The example's tuples describe selection information rather than prescribe a particular serialized key or database implementation.

Field matching itself follows the specification. It can include the normalization permitted for the nominated fields; comparing every raw header string byte for byte is not the general rule. A missing field and an arbitrary different value also cannot be silently treated as equivalent.^[ref]

Selection and permission to reuse are separate steps. A matching stored response must still satisfy the applicable cache controls and HTTP freshness or validation requirements. An HTTP private cache and an HTTP shared cache differ in their scope and some controls, but neither can infer complete reuse permission from a key match alone.^[ref]

The key becomes especially important with HTTP content negotiation: several representations can belong to one resource without being interchangeable for every request. Identifying the selection dimensions explains both correct reuse and why one broadly shared target identifier need not yield one universal cached body.

An HTTP shared cache stores HTTP responses for reuse by more than one user. It is often part of an intermediary, though that deployment is not required by the definition. An HTTP private cache is instead dedicated to a single user.^[ref]

For an own example, suppose four users request the same public manual through one shared cache. The first request obtains a complete, cacheable response with a $1200$-octet body. Assume the following three requests match the required HTTP cache key inputs, arrive while the stored response remains reusable, and have no directives requiring forwarding. They can be satisfied from that stored response. The origin then sends the body once instead of four times, avoiding $3(1200)=3600$ origin-body octets in this stipulated sequence. This does not count headers, validation traffic or delivery from the cache to the users.

Matching the target identifier alone need not be sufficient. If the response uses Vary: Accept, the relevant request-field matching rules also matter; one user's negotiated HTTP representation is not automatically suitable for another request's preferences.^[ref] HTTP content negotiation and cache selection therefore interact.

Storage and reuse are separate decisions. The unqualified Cache-Control: private response directive forbids storage by a shared cache. Other responses must still satisfy the ordinary storage constraints, and the cache must consider HTTP freshness or successful HTTP cache validation when constructing a later response.^[ref]

A shared cache also interprets s-maxage when present. For Cache-Control: max-age=600, s-maxage=60, its explicit freshness lifetime is sixty seconds rather than six hundred. This gives the origin a way to specify a shared reuse interval independently of the corresponding private-cache interval.^[ref]

The benefit comes from reusing an eligible response across users, not from assuming all users receive identical content. State selection inputs and cache controls before extrapolating the simple manual example to personalized or negotiated resources.

An HTTP private cache is dedicated to a single user. It is often implemented as part of a user agent, but its defining property is the single-user scope rather than a particular machine or storage medium. An HTTP shared cache can instead reuse responses for multiple users.^[ref]

Suppose a user's response carries Cache-Control: private, max-age=60. The unqualified private directive permits a private cache to store the response subject to the normal storage rules, while forbidding a shared cache from storing it. The max-age directive supplies its explicit HTTP freshness lifetime; it does not cancel the single-user storage restriction.^[ref]

If the correctly calculated HTTP current age is twenty seconds, sixty seconds exceeds that age and forty seconds remain until the freshness boundary. Reuse still requires matching the relevant request and satisfying other applicable constraints. At current age sixty, the strict freshness comparison fails; HTTP cache validation may then establish whether the stored representation remains suitable.^[ref]

Being private does not mean that every response must be stored or may be reused indefinitely. A cache can discard an entry, and an otherwise applicable restrictive directive remains significant. In particular, unqualified no-cache requires successful validation before subsequent reuse, whereas no-store prohibits the corresponding storage and reuse under its defined rules.^[ref]

The word private is also a cache-control distinction, not an encryption mechanism or a promise that the message is inaccessible to everyone else. The standard explicitly separates those meanings. Correct HTTP cache key selection and response handling still matter inside a single-user cache.^[ref]

For negotiated content, the stored representation can depend on request fields as well as the target. A private cache must therefore apply the same relevant matching rules rather than treating every request by its one user as interchangeable.

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]

HTTP freshness describes whether a stored HTTP response is young enough for reuse according to its applicable lifetime. The comparison isThe strict inequality matters: a response exactly at its lifetime boundary is no longer fresh.^[ref]

The HTTP freshness lifetime can come from explicit cache controls or, where permitted, a heuristic. The HTTP current age accounts for age accumulated before the response entered the present cache as well as its residence there. Counting only the seconds since this cache received the response can therefore underestimate its age.^[ref]

For an own example, suppose the applicable lifetime is $60$ seconds and the correctly calculated current age at a chosen instant is $20$ seconds. Keep the lifetime fixed. After another $30$ seconds, the age is $50$, so $60>50$ and the response remains fresh. After another $40$ seconds from the original instant, the age is $60$ and the strict comparison fails. After $45$ seconds it is $65$, again stale. These calculations start from a given current age; they do not derive it from local residence time alone.

Freshness and HTTP cache validation answer different questions. An old response might still match the origin's present HTTP representation. Validation can establish that reuse remains appropriate without retransmitting the representation body. Conversely, a fresh response has not thereby been checked against the origin at every use.^[ref]

Other rules still govern reuse. For example, the unqualified Cache-Control: no-cache response directive requires successful validation before subsequent use, even though the response can be stored. Stale-serving rules also have explicit conditions. A freshness calculation is therefore one part of deciding whether a stored HTTP response may satisfy a particular request, rather than a complete permission test.^[ref]

HTTP current age is a cache's estimate of an HTTP response's age at the time it is considered for reuse. It includes age accumulated before the response reached this cache and the time it has since spent there. The received Age field is therefore an input to the calculation, not generally the response's current age at every later instant.^[ref]

Write $t_q$ for the request time, $t_r$ for response receipt, $t_n$ for now, $D$ for the Date value and $a$ for the received Age value, all in compatible seconds. The RFC defines HTTP apparent age and HTTP response delay throughIt permits $a_{\mathrm{corr}}$ as the corrected initial age. For paths with very old caches, it also gives the more conservative choiceThe current age then adds local residence:The maximum-based choice is an allowed conservative alternative, not the only permitted initial-age calculation.^[ref]

For an own clock example, set $t_q=100$, $t_r=104$, $D=100$, $a=10$ and $t_n=110$. Assume adequately synchronized clocks and use the conservative choice. Apparent age is $4$, response delay is $4$, and corrected age is $10+4=14$. ThusUsing only local residence would have produced six seconds and substantially understated the estimated age.

If the HTTP freshness lifetime is $30$ seconds, this response is fresh at the example's current time because $30>20$. At $t_n=120$, its age reaches $30$ and that strict comparison fails. HTTP freshness still does not replace the other rules governing cache reuse or HTTP cache validation.

The calculation combines local intervals with metadata supplied by other machines. The apparent-age route assumes reasonable clock synchronization, while the delay-corrected route accounts for time spent obtaining the response. Treating Date or Age as a simple local stopwatch reading would lose those distinctions.^[ref]

In the HTTP current age calculation, HTTP response delay is the interval between the cache's request time and the time it receives the corresponding HTTP response:The interval corrects the age information carried in the response for time spent obtaining it. It is one input to cache-age estimation.^[ref]

For an own example, a cache initiates a request at local time $1000.0$ seconds and receives the response at $1003.5$. Its response delay is $3.5$ seconds. If the response carries Age: 12, the RFC's delay-corrected value isAfter another four seconds of local residence, using that corrected initial age would give $19.5$ seconds of current age.^[ref]

This interval does not isolate server computation. Transport, waiting and response handling can all contribute; a single elapsed interval does not reveal their separate amounts. Likewise, the received Date value comes from response metadata rather than defining either local endpoint of this subtraction.

The RFC permits the corrected age value as the corrected initial age. It also gives a conservative alternative that takes the maximum of that value and HTTP apparent age, particularly for paths involving old caches that might not supply appropriate Age information. The example uses the delay-corrected route explicitly instead of silently assuming both routes always agree.^[ref]

A correct elapsed-time calculation matters because HTTP freshness compares the resulting age with an HTTP freshness lifetime. Treating a received response as age zero simply because it has just reached the local cache would discard both the received age estimate and the acquisition interval.

HTTP apparent age estimates the age of an HTTP response at receipt by comparing its Date value with the receiving cache's clock. With receipt time $t_r$ and date value $D$ expressed in compatible seconds,The nonnegative clamp prevents a negative age when the date appears to lie in the receiver's future. The RFC describes this estimation route as relying on reasonable clock synchronization.^[ref]

For example, receipt time $104$ and date value $98$ give an apparent age of six seconds. With receipt time $104$ and date value $110$, the result is insteadThis zero does not establish that the representation was generated at the instant of receipt. A disagreement between clocks can conceal age in this comparison.

Another estimation route uses the received Age value and HTTP response delay. Suppose a request starts at $100$, its response arrives at $104$, the date value is $110$ and the received age is ten seconds. The apparent age is zero, while the delay-corrected value is $10+(104-100)=14$. The RFC's conservative maximum-based initial estimate therefore gives fourteen seconds rather than zero.^[ref]

After six more seconds in this cache, that initial estimate gives HTTP current age $14+6=20$. Apparent age itself is the receipt-time estimate; adding local residence belongs to the later current-age calculation. Keeping those stages distinct avoids adding the wrong interval or treating the original estimate as a permanently current value.

The result feeds HTTP freshness rather than replacing the full reuse decision. A small apparent age does not override cache controls, validate the current origin state or make every stored response eligible for reuse. It is useful precisely as one defined estimate with explicit inputs and assumptions.

The HTTP freshness lifetime is the duration against which an HTTP response's HTTP current age is compared to determine HTTP freshness. It can be specified explicitly or, where allowed, estimated by a cache. It is not the same as the amount of fresh time remaining: that depends on the response's current age as well.^[ref]

For valid explicit metadata, the RFC applies the first relevant rule. An HTTP shared cache uses s-maxage when present; otherwise max-age applies. If neither applicable directive is present, Expires supplies an expiration time from which the response's Date is subtracted, with the specified receipt-time fallback when Date is absent. Only when there is no explicit expiration time can HTTP heuristic freshness be applicable.^[ref]

Consider a response with Cache-Control: max-age=600, s-maxage=60. An HTTP shared cache, which serves more than one user, takes a $60$-second lifetime. An HTTP private cache, dedicated to one user, uses $600$ seconds instead. Assume the response otherwise satisfies the relevant storage and reuse rules.^[ref]

At current age $45$ seconds, the shared cache has $15$ seconds until its freshness boundary, while the private cache has $555$. At age $60$, the shared response is no longer fresh because $60>60$ is false; the private cache's comparison $600>60$ still succeeds. These are two cache policies for the same response metadata, not conflicting estimates of the response's age.

HTTP heuristic freshness is constrained estimation, not an instruction to assign every response an arbitrary lifetime. The RFC allows heuristics under specified conditions and does not prescribe one universal estimation algorithm.^[ref]

Finally, a computed lifetime does not override every other directive. Conflicting controls require the restrictive handling specified by the RFC; a freshness calculation also does not force a user agent to refresh its visible page. The lifetime governs cache operation, while the complete reuse decision still depends on the request and applicable response rules.^[ref]

HTTP heuristic freshness estimates an HTTP freshness lifetime when a stored HTTP response lacks explicit expiration information and is otherwise eligible for that treatment. It allows constrained reuse when the origin has not supplied a lifetime, without pretending that the origin explicitly guaranteed one.^[ref]

Eligibility comes first. The RFC permits heuristics for otherwise allowed responses that are heuristically cacheable by status or explicitly marked cacheable, when explicit freshness information is absent. A cache must not replace an explicit expiration time with its own heuristic. The ordinary storage constraints still apply.^[ref]

For an own example, assume a successful response satisfies those conditions and has no restrictive directives. Its Date corresponds to time $1000$ seconds and Last-Modified to $400$ seconds. Choose a cache policy that fixes its lifetime at one tenth of the interval between those timestamps:At HTTP current age $45$ seconds, $L>45$ and fifteen seconds remain until the freshness boundary. At age $60$, the strict comparison fails.

The fraction and exact timestamp policy are stated assumptions of this example. The RFC encourages a fraction of the interval since modification and mentions ten percent as a typical setting, but does not prescribe a universal heuristic algorithm or require that fraction.^[ref]

A long time since modification is evidence useful to an estimate; it is not proof that the origin will remain unchanged for the chosen lifetime. HTTP cache validation can later check whether a stored representation remains suitable. Different permitted heuristics can also produce different lifetimes from the same metadata.

An HTTP private cache and an HTTP shared cache must each respect the applicable caching constraints; being private or shared does not authorize arbitrary estimation. When an origin needs explicit freshness behavior, an explicit control such as max-age avoids relying on the cache to infer that lifetime.^[ref]

An HTTP persistent connection carries more than one HTTP request/HTTP response exchange over the same connection. HTTP/1.1 uses persistence by default unless its connection rules indicate closure. Reusing the connection avoids establishing a separate connection for every exchange.^[ref]

For a sequential example, a client retrieves /color and reads a response with Content-Length: 4 followed by blue. It then requests /shape on the same connection and reads Content-Length: 6 followed by circle. These are two distinct requests and two distinct responses, each with its own control information and HTTP message framing. Neither resource name nor method is inherited merely because the connection is reused.

This example relies on being able to finish the first message without closing the connection. To retain persistence, the message lengths must be self-defined rather than delimited by closure. A server must read the complete request body or close the connection after responding; otherwise leftover body bytes could be mistaken for a new request. A client likewise must consume the complete response body before reusing the connection.^[ref]

Connection: close signals that the connection will close after the current response. Persistence is not a promise of an unlimited lifetime: a connection can also close unexpectedly. Whether an outstanding operation can be retried automatically depends on its semantics, particularly HTTP idempotence, rather than on the fact that the connection had previously been reusable.^[ref]

Persistence also does not require sending requests before earlier responses arrive. That additional option is HTTP pipelining; in HTTP/1.1, the corresponding responses must retain request order. The sequential example uses persistence without pipelining.^[ref]

HTTP pipelining sends several HTTP requests on one HTTP persistent connection without waiting for each corresponding HTTP response before sending the next request. In HTTP/1.1, the server must send the responses in request order, even when it can process requests in parallel. Parallel processing of the sequence is permitted when its methods are all HTTP safe methods.^[ref]

For example, a client can send independent GET requests for /a, /b and /c before receiving the response for /a. The response for /a must come first, followed by those for /b and /c. Each response still needs correct HTTP message framing; persistence and pipelining do not merge three responses into one representation.

A simple timing model shows the motivation. Suppose an established connection has a round-trip propagation time of $100$ milliseconds, every request takes $10$ milliseconds of server processing, the server processes them sequentially, and transmission times are negligible. Waiting for each complete response before submitting the next gives arrival times $110$, $220$ and $330$ milliseconds at the client. Sending all three requests at time zero lets them reach the server together after $50$ milliseconds; their processing finishes at $60$, $70$ and $80$ milliseconds, so responses arrive at $110$, $120$ and $130$ milliseconds. These are stipulated model calculations, not measured browser performance.

Ordered responses also impose head-of-line blocking. If the first response cannot be completed promptly, a later response cannot pass it on this connection even if its computation is ready. The processing order and the permitted transmission order are therefore different constraints.

Pipelining also requires care after a failed connection: retrying outstanding requests is governed by method semantics and the protocol's recovery rules. HTTP idempotence helps determine when automatic repetition is justified. A client must not interpret the disappearance of a connection as proof that none of its outstanding operations took effect.^[ref]

HTTP message framing determines where an HTTP request or HTTP response ends and whether it is complete. The concrete rules depend on the protocol version. In HTTP/1.1, an empty line ends the header section, but the end of the message body requires the applicable length, transfer-coding or connection rules. A body can itself contain line breaks.^[ref]

Consider an ordinary successful response to GET whose text is café in UTF-8. Its four displayed letters occupy five octets, with hexadecimal values 63 61 66 c3 a9. With no transfer coding and no overriding bodyless-response rule, Content-Length: 5 therefore frames this body. Counting displayed characters would give the wrong boundary.^[ref]

An alternative is chunked transfer coding. Use Transfer-Encoding: chunked instead of the content-length field. The body can then be written in visible escape notation as 2\r\nca\r\n3\r\nfé\r\n0\r\n\r\n. Here \r\n denotes an actual carriage-return/line-feed pair, and the text is encoded in UTF-8. The first chunk supplies two octets; the second supplies three; the zero-sized chunk and empty trailer section finish the coding. This transfer-coded body occupies twenty octets and yields the same five content octets after decoding.^[ref]

Precedence matters. Responses to HEAD and responses with status 1xx, 204 or 304 have no message body even when fields appear to suggest a length. Some responses instead end with connection closure; requests are not close-delimited. Receiving fewer than the declared number of octets leaves a length-delimited message incomplete.^[ref]

Framing is separate from media type: a recipient first needs to delimit the transmitted data, then interpret its format. It also makes HTTP persistent connections possible, since a recipient can finish one exchange without treating connection closure as the only indication of completion.

Chunked transfer coding is a HTTP/1.1 transfer coding that wraps content in successive chunks, each preceded by its size in hexadecimal. It supplies HTTP message framing without requiring the sender to know the entire content length before starting transmission. The last chunk has size zero and is followed by any HTTP trailer fields and a final empty line.^[ref]

A response using this coding declares Transfer-Encoding: chunked. An own example of its complete body, written with visible escape notation, is A\r\nabcdefghij\r\n3\r\nXYZ\r\n0\r\n\r\n. Each \r\n denotes an actual carriage-return/line-feed pair; the other displayed characters are ASCII. Decode it as follows: A is hexadecimal ten, so consume the ten octets abcdefghij and their following line ending. The next size is three, so consume XYZ and its line ending. Zero then ends the chunks, and the final empty line ends the empty trailer section.

The recovered content is abcdefghijXYZ, with thirteen octets. This example's transfer-coded body occupies twenty-eight octets: fifteen for the first chunk, eight for the second, and five for the terminating zero-size line and empty trailer section. Those counts exclude the response start line and header section. Chunking provides boundaries; this example increases the number of transmitted octets rather than performing data compression.

A decoder must follow the declared octet counts. Chunk data can contain line endings of their own, so splitting the entire body into text lines is not a substitute for parsing the sizes. A sender can generate chunks progressively and retain an HTTP persistent connection after the message ends.^[ref]

The empty trailer section in the example can instead contain permitted HTTP trailer fields, for metadata available only after generating the content. These have their own applicability rules and cannot simply be merged indiscriminately into the earlier fields. If the stream ends before the terminating zero-sized chunk arrives, the message is incomplete.^[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 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]

HTTP/1.1 is a version of the Hypertext Transfer Protocol with a specified message syntax, parsing rules and connection behavior. Its shared method and status meanings come from the broader HTTP semantics; its concrete messages use a start line, field lines, an empty line and any permitted message body.^[ref]

A short response can be represented with visible escape notation as HTTP/1.1 200 OK\r\nContent-Length: 4\r\n\r\nblue. Here \r\n denotes the carriage-return/line-feed pair in the actual byte stream, rather than four literal characters. The body is the four bytes spelling blue; the empty line separates it from the header section.

This illustrates HTTP message framing: a recipient needs rules for locating the end of one message before interpreting subsequent bytes. In this example, the declared content length identifies four body bytes. Other permitted cases have their own framing rules; a line break inside body data is not automatically a new message.^[ref]

An HTTP persistent connection can carry multiple exchanges rather than requiring a fresh connection for each message. Persistence does not imply that a previous request's method or target is silently inherited by the next one; each request still has its own defined control information.^[ref]

Distinguish this wire format from the abstract HTTP request and HTTP response. A different HTTP version can encode control information differently while retaining shared meanings such as GET or status 200. Likewise, the protocol version alone does not identify the media type of a returned representation.

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.

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]

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]

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]

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]

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]

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 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]

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 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.

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]

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 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 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.

A URL, or Uniform Resource Locator, is a structured identifier interpreted according to a URL scheme and parsing rules. On the web it can identify the resource a browser navigates to or requests. The URL parser produces a record with components such as scheme, host, port, path, query and fragment; which components are present depends on the particular URL.^[ref]

For example, https://example.org:8443/a/b?x=1#part has scheme https, host example.org, port 8443, path /a/b, query string x=1 and fragment identifier part. This hierarchical HTTPS example is useful without implying that every URL must contain a network host or an explicit port.

A Relative URL reference needs a base. Resolving ../img/p.png against https://example.org/a/b/page.html gives https://example.org/a/img/p.png. The base's directory and parent-directory step explain the result. Parsing and serialization can also normalize a spelling: https://EXAMPLE.org:443/a serializes as https://example.org/a, lowercasing the host and omitting the default HTTPS port.^[ref]

Percent-encoding represents bytes in a URL spelling, and encoded data must be distinguished from structural delimiters. A query string is not universally a dictionary of name/value pairs, even though many applications use that convention. Nor does successful parsing prove that a resource is reachable or that its content never changes. Distinguishing syntax, identifier interpretation and an actual retrieval prevents an address from being confused with the information returned on one occasion.

A URL record is the structured internal representation of a URL, rather than its original text. The URL parser produces components such as scheme, host, port, path, query string and fragment identifier; URL serialization turns the record into a string. A component can be absent, and the representation of a path depends on the scheme.^[ref]

Parse https://example.org:8443/a?x=1#part. The host is example.org, the port is 8443, the path contains a, the query is x=1, and the fragment is part. The separators ? and # belong to the serialized syntax, rather than the stored query and fragment values. These fields let a program change one component without guessing its boundaries by cutting an arbitrary string.

The original spelling need not survive. Parsing https://EXAMPLE.org:443/a yields a lowercased host and no stored explicit port, because 443 is the scheme default. Therefore the record does not contain a faithful log of every character supplied by the user. If an application needs that log, it must retain the input separately.^[ref]

URL serialization produces the textual spelling of a structured URL record. It is the output side of processing that begins with a URL parser. The WHATWG serializer returns an ASCII string and can optionally omit the fragment identifier.^[ref]

A worked example separates the stages. Constructing new URL('https://EXAMPLE.org:443/a/../b?q=hello%20world~#top') gives href equal to https://example.org/b?q=hello%20world~#top. Lowercasing the host, removing the default port and resolving the parent-directory segment happen during parsing; the serializer exposes the resulting record.

Now call u.searchParams.sort() on that object. Even though there is only one query pair to sort, href becomes https://example.org/b?q=hello+world%7E#top. The decoded query value is unchanged, but URLSearchParams has rewritten its spelling using form URL encoding. Thus changing the query through an API can alter its percent-encoding without changing the value returned by that API.^[ref]

A serialized address is also different from a browser's chosen display text or a server's returned content. Comparing those different outputs answers different questions.

Percent-encoding represents a byte using a percent sign followed by two hexadecimal digits. For example, byte value 32 is written %20. Non-ASCII text is first encoded as bytes: in UTF-8, é becomes the two bytes hexadecimal C3 A9, represented as %C3%A9.^[ref]

A useful example distinguishes data from delimiters. The path in https://example.org/a/b has two segments; the path in https://example.org/a%2Fb retains the encoded slash within one segment in the parsed URL record. A server may apply additional decoding, but the two spellings must not be assumed interchangeable at every processing stage.

Percent-encoding is neither encryption nor a universal instruction to decode repeatedly. The string %252F decodes once to the text %2F; a second decoding changes it again. Likewise, the plus sign is not universally a space: that convention belongs to form-style query string processing, including URLSearchParams, rather than all URL components.^[ref]

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.

A query string is the component following ? and preceding #, or the end, in a URL. It carries data whose interpretation is defined by the resource or application. The generic syntax does not require a dictionary of names and values.^[ref]

For example, https://example.org/search?q=red&tag=a&tag=b#results has query q=red&tag=a&tag=b. An application using form-style conventions can interpret repeated tag entries as a list. URLSearchParams preserves repeated entries: getAll('tag') returns both a and b. Converting that list directly into a dictionary with one value per name can lose information.

Encoding conventions also matter. Under URLSearchParams parsing, q=a+b gives the value a b, while q=a%2Bb gives a+b. That distinction comes from the specified form parser, rather than a general law that every plus in every URL means a space.^[ref]

A useful test records both the original query string and the parsing convention. A changed spelling, changed list of values and changed server response are three different observations.

Form URL encoding is the application/x-www-form-urlencoded format for serializing an ordered list of name/value pairs. It is used by URLSearchParams and common form-processing conventions. Repeated names are allowed; the data model need not be a dictionary with one value per name.^[ref]

For example, the three pairs ("q", "a b+c"), ("tag", "x") and ("tag", "y") serialize as q=a+b%2Bc&tag=x&tag=y.
Here the space becomes +, while the literal plus in the value becomes %2B. Parsing the result recovers a b+c and both tag values. Replacing every plus with a space before deciding which encoding convention applies would misread data from other URL contexts.

Structural separators must also be distinguished from value data. The encoded pair q=a%26b has one value, a&b, rather than two pairs. The form parser first recognizes pair boundaries and then decodes their component data. Percent-encoding inside a component is consequently not an instruction to reinterpret the resulting characters as new separators.^[ref]

For modern serialization, text is encoded as UTF-8 bytes before the relevant bytes are percent-encoded. The name/value pair ("word", "café") therefore produces word=caf%C3%A9. This connects a text character with its byte representation rather than assigning one arbitrary percent code to the whole character.^[ref]

A query string can use this format, but generic URL syntax does not require every query to be interpreted this way. State the parser and encoding when comparing an original spelling with its recovered list of values.

URLSearchParams is an API for representing and manipulating an ordered list of name/value pairs, commonly obtained from a URL's query string. Repeated names are permitted. It uses form URL encoding, rather than imposing its interpretation on every conceivable query syntax.^[ref]

For new URLSearchParams('tag=a&tag=b&q=a+b'), getAll('tag') returns both a and b, while get('q') returns a b. Calling set('tag','c') replaces the repeated entries with one: toString() then returns tag=c&q=a+b. An associative array holding just one value for each name would discard the original repeated-field information.

A literal plus needs a different spelling. Appending the pair q and a+b to a URL's searchParams produces query ?q=a%2Bb. The plus in the data is represented by percent-encoding, whereas the plus in q=a+b represents a space under this parser. These examples distinguish a character in a value from a character used by the encoding convention.^[ref]

A URL's searchParams object is connected to that URL; changes update its query. Constructing a separate URLSearchParams from a query string instead gives an independent object, useful when the original spelling must remain available for comparison.^[ref]

A Relative URL reference identifies a target using a base URL to supply missing context. It can contain a path, a query string or a fragment identifier, without independently specifying an entire network address. Resolution combines the reference with the base according to a defined algorithm.^[ref]

Trailing slashes provide an illuminating comparison. Resolving c against https://example.org/a/b gives https://example.org/a/c; resolving it against https://example.org/a/b/ gives https://example.org/a/b/c. In the first case the last base path segment is replaced, while in the second it names a directory-like prefix.

A parent-directory step is similarly concrete: ../image.png against https://example.org/a/b/page.html gives https://example.org/a/image.png. These outcomes follow from URL processing, not from examining an actual filesystem. No network request is needed to calculate them.^[ref]

The base is therefore part of the input. Copying the same relative spelling into a document with a different base can change its target even when every character of the reference stays unchanged.

A URL parser is a procedure that turns input text, and sometimes a base URL, into a structured URL record or a failure. The record separates components such as scheme, host, path, query string and fragment identifier. URL serialization converts that structured result back into text; it is a different operation from retrieving the identified resource.^[ref]

For a worked example, parsing https://EXAMPLE.org:443/a and serializing the result yields https://example.org/a. The host is normalized and the default port omitted. Successful parsing did not test whether the server exists, whether access is permitted or what content would be returned.

Failure also differs from a recoverable validation issue. The WHATWG algorithms can flag some nonconforming input while still producing a record, so an implementation should specify whether it reports validation diagnostics, a usable result or both. A regular expression recognizing one tidy address format is not automatically an implementation of the full parser.

A practical reproducibility check compares parsed fields and the serialized output under a stated parsing model. The WHATWG model and generic RFC syntax serve related purposes but should not be silently treated as identical grammars.

A URL scheme is the leading component before :, selecting a family of interpretation and processing rules. For example, https is the scheme of https://example.org/a. Scheme syntax begins with an ASCII letter and then permits letters, digits, plus, hyphen and period. Comparison is case-insensitive, and standard serialization uses lowercase.^[ref]

The scheme does not imply that every URL names a remote server. Compare https://example.org/a with data:text/plain,hello: both have schemes, but the second example carries data in its own spelling rather than naming an HTTPS host. A URL parser must apply the appropriate rules rather than demand a host and port for every case.

The colon also separates a scheme from a familiar relative-path interpretation. The text a:b is parsed as a URL with scheme a, whereas ./a:b can be a Relative URL reference. Adding the initial dot and slash therefore changes the syntactic role of the colon-containing text.

Scheme-specific defaults matter too: omitting port 443 when serializing an HTTPS URL reflects that scheme's default, not a rule that all numerical ports are redundant.^[ref]

A computer network with nodes connected around a cycle. A unidirectional ring network permits messages to move only in the chosen direction.

Unicast addresses a transmission to a single destination, in contrast with group-addressed multicast delivery.

Multicast delivers data to a group of interested receivers. A multicast distribution tree can share transmissions over common links and copy them where routes branch.

A line code maps data to a sequence of physical signal levels or transitions for transmission. Timing, polarity and the length of runs of equal levels affect the choice.

A block code for line coding maps fixed-size groups of data bits to fixed-size transmitted codewords, chosen to meet signal constraints as well as to distinguish inputs. Constraints on long runs must also be checked across word boundaries.

Differential Manchester encoding has a transition at every bit midpoint and encodes the data by the presence or absence of a boundary transition. A consistent signal polarity reversal preserves those transition decisions.

Manchester encoding represents each data bit by two opposite half-bit levels. The compulsory midpoint transition supports clock recovery.

Clock recovery extracts a timing reference from a received signal so that a receiver can locate symbol boundaries.

The symbol rate, measured in baud, counts signal elements per second. Its relation to bit rate depends on the representation and on which signal element is counted as a symbol.

The bit rate counts transmitted data bits per unit time. State which representation is being counted: payload bits and encoded link bits need not have the same rate.

Network latency is the delay associated with communication over a network, distinguished from the rate at which data can be transferred. Moving a delivery endpoint closer to demand can reduce some path delay, but does not by itself establish application correctness or independent control.

The round-trip time measures the elapsed time for an exchange to travel to a peer and for a response to return. Feedback-based sending can be limited by this delay as well as by link capacity.

A router forwards network packets between networks using forwarding information. Ordinary Internet Protocol forwarding is distinct from a middlebox function that translates addresses, terminates a transport connection or applies an application-specific transformation.

Packet switching carries separately represented units of data over shared communication links. Different packets can share forwarding resources; the network service need not reserve one dedicated circuit for an entire application exchange.

A network packet carries a unit of data together with protocol information used to interpret or deliver it. Internet Protocol carries datagrams; transport and application messages can span several such packets.

A layered network architecture separates responsibilities behind communication interfaces. A transport protocol can offer an application a service built over Internet Protocol without requiring each underlying network to implement that application. Layer boundaries are engineering choices: the end-to-end principle helps assess which properties a lower layer can actually establish.

The data link layer organizes communication over a link, typically using data-link frames and local checking or access rules.

Framing identifies the boundaries of data-link frames in a transmitted stream, allowing a receiver to locate separately interpretable link-level units.

Bit stuffing inserts extra bits according to an agreed rule, for example after five consecutive ones, so that a reserved frame delimiter cannot occur inside encoded contents. The receiver reverses the insertion rule.

A frame delimiter marks a data-link frame boundary. A transparency rule such as bit stuffing prevents data from accidentally imitating the reserved delimiter.

A data-link frame is a delimited unit of link-level transmission containing data and any associated control or checking fields.

A transport protocol provides communication services between its transport endpoints over an underlying network. Transmission Control Protocol supplies a reliable ordered byte stream; User Datagram Protocol supplies datagrams without that built-in recovery service. Applications can implement further mechanisms over either interface.

Flow control limits a sender according to a receiver's buffering or processing capacity, rather than the capacity of the intervening computer network.

A dependency by which an unready receiver delays upstream acceptance of further work. In synchronous message passing it can propagate through a chain of blocked sends; a finite buffer postpones this propagation until its capacity is used.

A sliding window protocol permits a range of numbered data to be outstanding or accepted, advancing that range as transmission makes progress.

A receive window bounds the numbered data a receiver is prepared to accept. In TCP, the receiver advertises a window that limits the sender independently of the sender's congestion window.

A send window specifies the numbered data a sender may transmit before further progress permits the range to advance.

An acknowledgement reports receipt according to the protocol's rules. A TCP cumulative acknowledgement names the next expected byte; it does not establish that the application has durably acted on all preceding data.

A delayed acknowledgement postpones a response briefly so that one acknowledgement may cover more data or accompany returning data. Its timer can interact with Nagle's algorithm to delay a short exchange.

A transport sequence number identifies a data position within an exchange, supporting ordering, duplicate rejection and precise acknowledgements. TCP numbers bytes rather than simply numbering packets.

Data retransmission sends data again to recover from loss or detected corruption. Transport sequence numbers let a receiver recognize a duplicate if the original transmission arrived but its acknowledgement was lost.

A transport port is a numbered identifier used by a transport protocol to distinguish communication endpoints at a host. TCP and UDP have separate port spaces.

QUIC is a transport protocol over User Datagram Protocol that provides multiple flow-controlled streams, cryptographic protection and connection migration. RFC 9000 published the version-1 transport specification in May 2021. Several streams can share one connection while retaining separate ordering: loss affecting one stream need not stop delivery of already available data on another. Congestion control and connection-wide limits still couple their use of network resources.^[ref]

At the 17 January 2020 examination date, the cited November 2019 design was an Internet-Draft and work in progress. This historical description does not treat a later standard as already available.^[ref]

User Datagram Protocol supplies a datagram transport interface without built-in reliable ordered-stream delivery. An application or another protocol can add recovery over that interface, as the pre-2020 QUIC design illustrates.

Transmission Control Protocol provides a reliable ordered byte-stream service between its endpoints, using sequencing, acknowledgements and retransmission. Receipt by that transport does not establish that a receiving application has durably stored the data or completed a user operation.^[ref]

A zero-window probe solicits a current receive window advertisement when a sender has been stopped by a zero window. Repeated probes recover from a lost reopening acknowledgement.

The persist timer schedules repeated zero-window probes, preventing an exchange from waiting forever after a window-reopening message is lost.

Silly window syndrome is inefficient transmission in tiny TCP segments, arising through small writes or small increments of advertised receiving space. Sender and receiver measures address different causes.

Nagle's algorithm coalesces small writes while data are unacknowledged, permitting another send when a full TCP segment can be formed or the outstanding data have been acknowledged. It reduces tiny transmissions but can add delay.

A TCP segment contains a TCP header and zero or more data bytes. The header carries sequencing, acknowledgement and receive window information.

The Internet interconnects independently operated computer networks using the Internet Protocol suite. Its common inter-network interface supports diverse underlying networks and applications; individual services can still depend on centrally controlled providers.

A content delivery network uses delivery infrastructure, often at multiple locations, to supply content and direct requests to suitable delivery endpoints. It can retain objects through caching or retrieve them from an origin. Distribution across sites does not imply that those sites have independent administrative control.^[ref]

A CDN edge is a delivery endpoint of a content delivery network. It may use caching or fetch content, and a provider can authorise it to terminate a client connection. Its location near demand and its administrative authority are separate properties.

The Domain Name System provides a hierarchical namespace with delegated administration and distributed servers. Caching and replication help supply its service. A consistent namespace is compatible with distribution of responsibility across organisations.^[ref]

Internet Protocol supplies an inter-network datagram interface. Its basic packet delivery does not itself guarantee arrival, order, absence of duplicates or completion of an application operation. IPv4 and IPv6 are versions of this network-layer protocol.

IP multicast sends an Internet Protocol datagram to a group identified by a multicast IP address. Delivery retains the underlying best-effort nature of Internet Protocol.

Multicast routing establishes and maintains the forwarding decisions that deliver group-addressed packets to interested receivers.

Reverse path forwarding accepts a source's multicast traffic only on the interface selected for the reverse route to that source. With consistent loop-free routing, those parent choices define a source-rooted tree. Membership pruning can then remove unneeded branches.

A multicast distribution tree describes the parent and outgoing branches used to distribute packets to a group. Source-rooted and shared-group designs make different state and path choices.

IPv6 uses 128-bit addresses and a revised packet format. More address space does not remove firewalls or decide which application providers must be trusted.^[ref]

IPv4 uses 32-bit addresses. Address sharing through network address and port translation is one response to pressure on its globally usable address space.

An IP address identifies an interface or destination according to the relevant Internet Protocol addressing rules. It is not inherently the identity of a person, and address translation can change the address visible across a boundary.

The Internet architecture comprises its protocol interfaces, addressing and naming arrangements, placement of functions and assumptions about communication. Physical connectivity, administrative control and application trust are distinct dimensions of this architecture.^[ref]

Internet service federation permits independently administered services to communicate through agreed protocols. Internet mail is an example: separate domains can exchange messages without every user joining one provider. Federation differs from placing many replicas behind one mandatory account authority, and it does not itself establish cryptographic confidentiality or freedom from software failures.^[ref]

A middlebox performs a function on a communication path beyond ordinary Internet Protocol forwarding, such as address translation, traffic filtering or proxying. The function can be embedded in a device rather than implemented in a separate physical box. Its state and assumptions can affect failure recovery and protocol evolution.^[ref]

A proxy server performs communication operations on behalf of another participant. Whether it can inspect plaintext depends on the protocols and keys it uses: relaying opaque encrypted bytes differs from authorised TLS termination.