HTTP reference

The server has received the request headers and the client should go on to send the body. It is an interim response; the final status follows.

Typical use: Sent after a client asks with Expect: 100-continue, so a large upload is not sent to a server that would reject it anyway.

RFC 9110 §15.2.1

The server agrees to the client’s Upgrade request and switches the connection to the protocol named in its own Upgrade header.

Typical use: The handshake for WebSocket connections (and, historically, h2c upgrades).

RFC 9110 §15.2.2

An interim response from WebDAV telling the client that the server has accepted the full request but has not finished it, so the client should not time out.

Typical use: Long-running WebDAV operations; rarely used today and dropped from the later WebDAV specification.

RFC 2518 §10.1

An interim response carrying headers, usually Link, that the client can act on while the server is still preparing the final response.

Typical use: Lets browsers preload or preconnect to critical CSS, fonts and origins while the HTML is being generated.

RFC 8297 §2

The request succeeded. What the body holds depends on the method: the resource for GET, the result of the action for POST, nothing for HEAD.

Typical use: The default success response for pages, API reads and most actions that return a body.

RFC 9110 §15.3.1

The request succeeded and created one or more new resources. The Location header, if present, points at the main new resource.

Typical use: A successful POST or PUT that creates a record in a REST API.

RFC 9110 §15.3.2

The request has been accepted for processing, but processing is not complete and may still fail. There is no way to send the final outcome later in the same response.

Typical use: Queued or asynchronous jobs; the body often links to a status endpoint to poll.

RFC 9110 §15.3.3

The request succeeded, but a transforming proxy has changed the content from the origin server’s 200 response.

Typical use: Proxies that rewrite or annotate responses; seldom seen in practice.

RFC 9110 §15.3.4

The request succeeded and there is no content to send. The response cannot have a body; headers such as ETag still apply.

Typical use: Successful DELETE or PUT calls, saves that need no reply, and CORS preflight responses.

RFC 9110 §15.3.5

The request succeeded and the client should reset the document view that sent it, for example clear a form.

Typical use: Data entry forms that should be emptied after submission; browsers largely ignore it.

RFC 9110 §15.3.6

The server is sending only the part of the resource asked for in the Range header, described by Content-Range (or a multipart/byteranges body).

Typical use: Resuming downloads, seeking in audio and video, and parallel chunked downloads.

RFC 9110 §15.3.7

The body is an XML document with separate status codes for several resources or operations.

Typical use: WebDAV operations such as PROPFIND that act on many resources at once.

RFC 4918 §11.1

Inside a WebDAV multi-status response, the members of this binding were already listed earlier and are not repeated.

Typical use: WebDAV binding extensions, to avoid listing the same collection twice.

RFC 5842 §7.1

The server fulfilled a GET and the response is the result of one or more instance manipulations, such as a delta, applied to the current instance.

Typical use: HTTP delta encoding; almost never used.

RFC 3229 §10.4.1

The resource has several representations, each with its own location, and the client or user should pick one.

Typical use: Rare; content negotiation is usually done without asking the user.

RFC 9110 §15.4.1

The resource has a new permanent URL, given in Location. Clients may change POST to GET when following it, for historical reasons.

Typical use: Permanent URL changes and HTTP to HTTPS redirects; search engines move ranking to the new URL.

RFC 9110 §15.4.2

The resource is temporarily at another URL, given in Location. Clients may change POST to GET when following it.

Typical use: Temporary redirects, login redirects and the classic redirect after a form post.

RFC 9110 §15.4.3

The response to this request is at another URL, which the client should fetch with GET, whatever the original method was.

Typical use: The Post/Redirect/Get pattern: send the user to a result page after a form submission.

RFC 9110 §15.4.4

A conditional GET or HEAD found that the resource has not changed, so the client can use its cached copy. The response has no body.

Typical use: Cache revalidation with If-None-Match or If-Modified-Since.

RFC 9110 §15.4.5

Defined in an earlier HTTP specification to ask the client to repeat the request through a proxy.

Typical use: Not used; browsers ignore it for security reasons.

Deprecated because it let a server pick a proxy for the client.

RFC 9110 §15.4.6

Was “Switch Proxy” in a draft specification. The code is reserved and no longer has a meaning.

Typical use: Never sent.

Reserved.

Also called Switch Proxy. RFC 9110 §15.4.7

The resource is temporarily at the URL in Location, and the client must repeat the request there with the same method and body.

Typical use: Temporary redirects that must keep POST as POST, and browser-internal HSTS upgrades.

RFC 9110 §15.4.8

The resource has a new permanent URL in Location, and the client must repeat the request there with the same method and body.

Typical use: Permanent moves of API endpoints or any URL that receives POST, PUT or DELETE.

RFC 9110 §15.4.9

The server cannot or will not process the request because of something it sees as a client error, such as malformed syntax or invalid framing.

Typical use: Malformed JSON, missing required parameters and general validation failures.

RFC 9110 §15.5.1

The request lacks valid authentication credentials. The response must include a WWW-Authenticate header with a challenge saying how to authenticate.

Typical use: Missing or expired tokens and wrong passwords; the client should sign in and retry.

Also called Unauthenticated. RFC 9110 §15.5.2

Reserved for future use. No standard behaviour is defined.

Typical use: Some APIs and SaaS products use it for unpaid accounts or exhausted quotas.

RFC 9110 §15.5.3

The server understood the request but refuses to fulfil it. Unlike 401, authenticating again will not help.

Typical use: Insufficient permissions, blocked IP addresses and CSRF check failures.

RFC 9110 §15.5.4

The server has no current representation of the target resource, or will not say that one exists. It says nothing about whether this is temporary.

Typical use: Unknown URLs and missing records; also used instead of 403 to hide that a resource exists.

RFC 9110 §15.5.5

The resource exists but does not support the request method. The response must include an Allow header listing the methods it does support.

Typical use: POST to a read-only endpoint, or DELETE where deletion is not offered.

RFC 9110 §15.5.6

The resource has no representation that matches the client’s Accept, Accept-Language or Accept-Encoding headers, and the server will not send a default.

Typical use: Strict content negotiation in APIs; most servers send a default representation instead.

RFC 9110 §15.5.7

Media types the client can handle, in order of preference with optional q weights.

content · RFC 9110 §12.5.1

Client hints the server wants the browser to send on later requests.

client hints · RFC 8942 §3.1

Content codings (compression) the client understands.

Note: Servers that compress based on it should send Vary: Accept-Encoding.

content · RFC 9110 §12.5.3

Natural languages the user prefers, as BCP 47 tags with optional weights.

content · RFC 9110 §12.5.4

Says whether the server supports range requests for this resource, and in which unit.

range · RFC 9110 §14.3

Lets the page read a cross-origin response to a request made with credentials (cookies, HTTP auth).

Note: With true, Access-Control-Allow-Origin must name the origin; * is refused.

cors, security · Fetch Standard, CORS protocol

Request headers allowed in the actual request, sent in reply to a preflight.

Note: * works only for requests without credentials and never covers Authorization.

cors · Fetch Standard, CORS protocol

Methods allowed in the actual request, sent in reply to a preflight.

cors · Fetch Standard, CORS protocol

Which origin may read the response: one origin, * or null.

Note: Only one origin is allowed; to allow several, echo a vetted request Origin and send Vary: Origin. Never echo every origin together with credentials.

cors, security · Fetch Standard, CORS protocol

Response headers, beyond the safelisted ones, that scripts may read.

cors · Fetch Standard, CORS protocol

How many seconds the browser may cache a preflight result.

Note: Browsers cap it: Chromium at 2 hours, Firefox at 24 hours.

cors, caching · Fetch Standard, CORS protocol

Sent in a preflight: the non-safelisted headers the actual request will use.

cors · Fetch Standard, CORS protocol

Sent in a preflight: the method the actual request will use.

cors · Fetch Standard, CORS protocol

Seconds since the response was generated or revalidated at the origin, added by caches.

caching · RFC 9111 §5.1

Methods the resource supports. Required with 405 Method Not Allowed.

content · RFC 9110 §10.2.1

Advertises other protocols or endpoints that serve the same origin, such as HTTP/3.

connection · RFC 7838 §3

Credentials that authenticate the client with the origin server.

Note: Not a CORS-safelisted header: cross-origin requests that send it need a preflight. Browsers drop it on cross-origin redirects.

auth, security · RFC 9110 §11.6.2

Caching directives: max-age, no-cache (revalidate first), no-store (never store), private, public, immutable, stale-while-revalidate and more.

Note: Use no-store for responses with personal data; no-cache still stores the response.

caching · RFC 9111 §5.2

How each cache along the path handled the request: hit, forwarded, stored, and why.

caching, proxy · RFC 9211 §2

Cache directives aimed only at CDNs, overriding Cache-Control for them.

caching, proxy · RFC 9213 §2

Tells the browser to clear cookies, storage, cache or execution contexts for the origin.

Note: Useful on sign-out. Only honoured over HTTPS.

security, cookies · W3C Clear Site Data

Options for the current connection, such as close, and the hop-by-hop headers that must not be forwarded.

Note: Forbidden in HTTP/2 and HTTP/3.

connection · RFC 9110 §7.6.1

Whether the body is shown inline or downloaded as an attachment, and the suggested file name.

Note: Also used inside multipart/form-data parts to name each field.

content · RFC 6266 §4

Compression applied to the body, which the recipient must undo.

content · RFC 9110 §8.4

Natural language of the intended audience of the content.

content · RFC 9110 §8.5

Size of the body in bytes.

content · RFC 9110 §8.6

A URL for the specific representation returned, when it differs from the request URL.

content · RFC 9110 §8.7

Which part of the full resource a partial body holds, and the full size.

range · RFC 9110 §14.4

Restricts where scripts, styles, images, frames and other resources may load from.

Note: A strict nonce- or hash-based policy is the main defence in depth against XSS.

security · W3C CSP Level 3

Reports CSP violations without blocking anything, to test a policy before enforcing it.

security, reporting · W3C CSP Level 3

HTML document · .html.htm

Cascading Style Sheets · .css

JavaScript; the official type since RFC 9239 · .js.mjs

Plain text · .txt.text.log

Comma-separated values · .csv

Tab-separated values · .tsv

Markdown · .md.markdown

iCalendar event or calendar · .ics

vCard contact · .vcf.vcard

XML that is readable as text; prefer application/xml

Server-sent events stream

WebVTT subtitles and captions · .vtt

Rich Text Format · .rtf

Python source · .py

C source · .c.h

Java source · .java

Shell script · .sh

JSON · .json

JSON-LD linked data · .jsonld

Web app manifest · .webmanifest

GeoJSON · .geojson

Problem details for HTTP APIs (RFC 9457)

JSON Patch (RFC 6902)

JSON Merge Patch (RFC 7396)

Newline-delimited JSON · .ndjson.jsonl

XML document · .xml.xsd.xsl

XHTML document · .xhtml

Atom feed · .atom

RSS feed · .rss

YAML (RFC 9512) · .yaml.yml

Fallback for every fetch directive that is not set.

Note: Start strict ('none' or 'self') and open up per resource type.

Where scripts may load from and whether inline scripts, event handlers and eval may run.

Note: A nonce or hash with 'strict-dynamic' is the recommended strict policy; host allowlists are easy to bypass.

Falls back to default-src.

Sources for <script> elements only, overriding script-src for them.

Falls back to script-src.

Inline event handler attributes such as onclick.

Falls back to script-src.

Where style sheets may load from, and whether inline styles may apply.

Falls back to default-src.

<style> elements and <link rel="stylesheet">.

Falls back to style-src.

Inline style attributes on elements.

Falls back to style-src.

Images and favicons.

Falls back to default-src.

Fonts loaded with @font-face.

Falls back to default-src.

URLs scripts may contact: fetch, XHR, WebSocket, EventSource and sendBeacon.

Falls back to default-src.

<audio>, <video> and <track> sources.

Falls back to default-src.

<object> and <embed> plugin content.

Note: Set it to 'none'; plugins are a common bypass.

Falls back to default-src.

Pages that may load in <iframe> and <frame> on this page.

Falls back to child-src, then default-src.

Frames and workers, when frame-src or worker-src is not set.

Falls back to default-src.

Scripts for Worker, SharedWorker and service workers.

Falls back to child-src, then script-src, then default-src.

Web app manifests.

Falls back to default-src.

URLs allowed in <base href>, which changes how relative URLs resolve.

Note: Does not fall back to default-src; set it, or injected <base> tags can redirect scripts.

Applies iframe-style sandbox restrictions to the page, with allow-* exceptions.

Note: Ignored in <meta> policies and in report-only mode.

URLs forms on the page may submit to.

Note: Does not fall back to default-src.

Which pages may embed this one in a frame; protects against clickjacking.

Note: Replaces X-Frame-Options. Ignored in <meta> policies; send it as a header.

Names a Reporting-Endpoints group that violation reports are sent to.

URL that receives violation reports as JSON POST requests.

Note: Still the only reporting option in some browsers; send it together with report-to.

Replaced by report-to.

Rewrites the page’s http: subresource and same-site navigation URLs to https: before fetching.

Makes DOM XSS sinks such as innerHTML accept only Trusted Types objects: 'script'.

Names the Trusted Types policies the page may create.

Blocked every http: subresource on an https: page.

Browsers now upgrade or block mixed content themselves.

The page’s own origin (scheme, host and port); also allows the https: and wss: upgrades of it.

Nothing; must be the only value of the directive.

Allows inline <script>, <style>, event handlers and javascript: URLs.

Note: Defeats most XSS protection for scripts. Ignored when a nonce or hash is also present.

Allows eval(), new Function() and string arguments to setTimeout.