Cookies Having Independent Partitioned State (CHIPS) - Privacy on the web

Cookies Having Independent Partitioned State (CHIPS)
====================================================

**Experimental:** **This is an experimental technology**
Check the Browser compatibility table carefully before using this in production.

**Cookies Having Independent Partitioned State** (**CHIPS**, also known as **Partitioned cookies**) allows developers to opt a cookie into partitioned storage, with a separate cookie jar per top-level site.

A partitioned third-party cookie is tied to the top-level site where it's initially set and cannot be accessed from elsewhere. The aim is to allow cookies to be set by third-party services, but only read within the context of the top-level site where they were initially set. This allows cross-site tracking to be blocked, while still enabling non-tracking uses of third-party cookies such as persisting state of embedded maps or chat widgets across different sites, and persisting config information for subresource CDN load balancing and Headless CMS providers.

Cross-site tracking in a nutshell
---------------------------------

Historically, when a site embeds content via an `<iframe>`, the embedded content can set a cookie on the user's device in response to the cross-site request. If the user visits other sites that embed the same content, the embedded content can access the same cookie originally set by the first instance of the embedded content. This enables the content owner to track user activity across these sites, and any other sites that embed the same content.

For example:

1. A user visits `https://site-a.example`, which embeds content from `https://3rd-party.example`. `https://3rd-party.example` sets a cookie on the user's device.
2. The user visits `https://site-b.example`, which also embeds `https://3rd-party.example`. This new instance of `https://3rd-party.example` is still able to access the cookie set when the user was on the previous page.

This works because cookies are currently stored with a key based on the host or domain name of the site that set them, aka the **host key**. In the above case the cookie would be stored with a key of `("3rd-party.example")`.

User privacy is a foremost concern, so browsers are starting to restrict how this behavior can be used to track users, however there are still valid uses for third-party cookies, as described above. CHIPs enables these uses cases and more, while still allowing browsers to preserve user privacy.

How does CHIPS work?
--------------------

Browsers with CHIPs support provide a new attribute for the `Set-Cookie` HTTP header — `Partitioned` — which when set allows site owners to opt-in to using CHIPs:

```http
Set-Cookie: \_\_Host-example=34d8g; SameSite=None; Secure; Path=/; Partitioned;
```

**Note:** Partitioned cookies must be set with `Secure`. In addition, it is recommended to use the `__Host` prefix when setting partitioned cookies to make them bound to the hostname and not the registrable domain.

With `Partitioned` set, the cookie is stored using two keys, the host key and a new **partition key**. The partition key is based on the scheme and eTLD+1 of the top-level URL the browser was visiting when the request was made to the URL endpoint that set the cookie.

Revisiting the example we described in the previous section:

1. A user visits `https://site-a.example`, which embeds content from `https://3rd-party.example`. `https://3rd-party.example` sets a cookie on the user's device using `Partitioned`, meaning that the site owner opts in to CHIPS.
2. The storage key for the cookie would now be `{("https://site-a.example"), ("3rd-party.example")}`.
3. When the user visits `https://site-b.example`, which also embeds `https://3rd-party.example`, this new embedded instance is no longer able to access the cookie because the partition key doesn't match.

**Note:** CHIPS is similar to the older State partitioning mechanism implemented by Firefox. The difference is that state partitioning partitions cookie storage and retrieval into separate cookie jars for each top-level site, without a mechanism to allow opt-in to third-party cookies if desired. As browsers start to phase out third-party cookie usage, there are still valid, non-tracking uses of third-party cookies that need to be permitted while developers begin to handle this change.

A valid third-party embed scenario
----------------------------------

Blocking all third-party cookies would currently be problematic, for example in a retail site that uses a third-party chat service, as described below. CHIPs will enable this use case, while third-party tracking cookies are blocked.

1. A user visits `https://shoppy.example`, which embeds a third-party chat service from `https://3rd-party.example/chat` to provide support for users that need help. `https://3rd-party.example/chat` sets a cookie on the user's device using `Partitioned`, to persist the state of the chat across different site subdomains.
2. The storage key for the cookie would be `{("https://shoppy.example"), ("3rd-party.example/chat")}`.
3. The user visits various subdomains in the quest to solve their problem that also embed `https://3rd-party.example/chat`, including `https://support.shoppy.example` and `https://checkout.shoppy.example`. The new embedded instances are able to access the cookie because the partition key still matches.
Specifications
--------------

| Specification |
| --- |
| Cookies Having Independent Partitioned State specification # section-2.1 |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* Cookies Having Independent Partitioned State (CHIPS) on developer.chrome.com
* CHIPS Explainer


Firefox tracking protection - Privacy on the web

Firefox tracking protection
===========================

What is tracking protection?
----------------------------

Firefox Desktop and Firefox for Android include built-in tracking protection. In Private Browsing windows (tabs, in Firefox for Android), Firefox will block content loaded from domains that track users across sites.

If blocked content is part of the page layout, users may notice layout issues where Firefox blocked these loads. Sometimes users won't notice at all, if the page grid works such that other page elements slide in to fill holes left by blocked elements.

When Firefox blocks content, it logs a message to the Web Console like this:
```

The resource at "http://some/url" was blocked because tracking protection is enabled.
```

Note that with Firefox for Android, you can access console output using the remote debugger.

![Page information showing possible blocked content.](/en-US/docs/Web/Privacy/Firefox_tracking_protection/blocked_content.png)

Click the ⓘ symbol in the address bar to view information about the currently loaded page. The popup that appears will notify you when content has been blocked. You will also be able to disable tracking protection entirely if you choose by accessing the tracking settings.

If tracking cookies were present, you would be able to view the list by clicking on "Blocking Tracking Cookies" in the above image to view the following popup:

![Page information showing cookies and site data.](/en-US/docs/Web/Privacy/Firefox_tracking_protection/tracking_cookies.png)

You can click "Manage Content Blocking" to change the blocking settings:

![There are 3 levels of content blocking, standard, strict, or custom, which can be set to always on or only on when firefox is set to block known trackers.](/en-US/docs/Web/Privacy/Firefox_tracking_protection/content_blocking.png)

How does Firefox choose what to block?
--------------------------------------

Content is blocked based on the domain from which it is to be loaded.

Firefox ships with a list of sites which have been identified as engaging in cross-site tracking of users. When tracking protection is enabled, Firefox blocks content from sites in the list.

Sites that track users are most commonly third-party advertising and analytics sites.

What does this mean for your website?
-------------------------------------

Most obviously, it means that when tracking protection is enabled:

* content served from third-party trackers will not be visible to users
* your site won't be able to use third-party advertising or analytics services that engage in tracking

More subtly, if other parts of your site depend on trackers being loaded, then these parts will also be broken when tracking protection is enabled. For example, if your site includes a callback that runs when content from a tracking site is loaded, then the callback will not execute.

For example, you should not use Google Analytics in the following way:

```html
<a
 href="http://www.example.com"
 onclick="trackLink('http://www.example.com', event);">
  Visit example.com
</a>

<script>
 function trackLink(url, event) {
 event.preventDefault();
 ga("send", "event", "outbound", "click", url, {
 transport: "beacon",
 hitCallback() {
 document.location = url;
 },
 });
 }
</script>
```

Instead, you should account for the case when Google Analytics is missing by checking to see if the ga object has initialized:

```html
<a
 href="http://www.example.com"
 onclick="trackLink('http://www.example.com', event);">
  Visit example.com
</a>

<script>
 function trackLink(url, event) {
 event.preventDefault();
 if (window.ga && ga.loaded) {
 ga("send", "event", "outbound", "click", url, {
 transport: "beacon",
 hitCallback() {
 document.location = url;
 },
 });
 } else {
 document.location = url;
 }
 }
</script>
```

More information about this technique is available at Google Analytics, Privacy, and Event Tracking.

**Note:** Depending on a third party in this way is not a good practice anyway, because then your site can be broken if the third party is slow or unavailable, or if the tracker has been blocked by an add-on.


Storage access policy: Block cookies from trackers - Privacy on the web

Storage access policy: Block cookies from trackers
==================================================

Firefox includes a new storage access policy that blocks cookies and other site data from third-party tracking resources. This policy is designed as an alternative to the older cookie policies, which have been available in Firefox for many years. This policy protects against cross-site tracking while minimizing the site breakage associated with traditional cookie blocking. This article explains how the policy works and how you can test it.

Testing in Firefox
------------------

This cookie policy has been available in Firefox since version 63. This documentation describes the policy that we intend to ship to Firefox Release users, but may not match what is implemented in the current Release version of Firefox. That's because we document new aspects of the policy as soon as they land in Firefox Nightly, our pre-release channel. Firefox Nightly may also contain experimental features that we don't yet plan to ship to Release users; experimental features will not be included in this documentation, but may nevertheless impact the functionality of domains classified as trackers.

We recommend sites test with Firefox Nightly, as this includes the newest version of our protections. As described above, note that Nightly may include additional protections that end up getting removed or changed before they reach our Release users. We'll keep this page updated with the newest information as we strengthen our protections.

These protections are on by default in Nightly. The cookie policy can be enabled in other versions of Firefox through the Content Blocking settings (these steps will vary by version; the linked documentation includes a dropdown to select the appropriate Firefox version).

### Report Broken Sites

If you find a website broken as a result of this change, file a bug under the Tracking Protection component within the Firefox product on Bugzilla. Alternatively you can report broken sites directly in Firefox by clicking "Report a Problem" in the Content Blocking section of the Control Center (this shortcut may not be available in all versions of Firefox).

Tracking protection explained
-----------------------------

How does Firefox determine which resources are tracking resources?

Firefox uses the Tracking Protection list to determine which resources are tracking resources. The Tracking Protection list is maintained by Disconnect. When the list is applied in Firefox, we make two important changes:

* First, we only use the "Basic Protection" version of the list, which excludes some categories of trackers. In the future, we may expand our protections to use the "Strict Protection" version of the list.
* Second, Firefox uses an additional "entity list", which prevents domains from being classified as trackers when they are loaded on a top-level site owned by the same organization.

Firefox uses the built-in Tracking Protection URL classifier to determine which resources match the tracking protection list. Domains are matched against the list in accordance with the SafeBrowsing v4 specification. Specifically, we check the exact hostname of the resource against the list, as well as the last four hostnames formed by starting with the last five components and successively removing the leading component. Consider the following examples:

| Hostname on the list | Hostname of resource | Matched |
| --- | --- | --- |
| `example.com` | `example.com` | Yes |
| `example.com` | `a.b.example.com` | Yes |
| `blah.example.com` | `example.com` | No |
| `a.b.example.com` | `c.d.example.com` | No |
| `blah.example.com` | `foo.blah.example.com` | Yes |

What does the storage access policy block?
------------------------------------------

The storage access policy blocks resources identified as trackers from accessing their cookies and other site storage when they are loaded in a third-party context. This prevents those resources from retrieving tracking identifiers stored in cookies or site storage and using them to identify users across visits to multiple first parties. Specifically, Firefox does this by imposing the following restrictions:

Cookies:

* Block `Cookie` request headers and ignore `Set-Cookie` response headers.
* Return an empty string for calls to `Document.cookie` and ignore requests to set cookies via `Document.cookie`.

DOM Storage:

* localStorage: `Window.localStorage`: read and write attempts throw a `SecurityError` exception. Prior to Firefox 70: `Window.localStorage` is `null`. Thus, attempts to read and write using this object will throw a `TypeError` exception.
* sessionStorage: read and write attempts are permitted.
* IndexedDB: attempting to access the IndexedDB factory object throws a `SecurityError` exception.

Messaging and Workers:

* Broadcast Channel: attempts to create a new `BroadcastChannel` will throw a `SecurityError` exception.
* Shared Worker: attempts to create a new `SharedWorker` will throw a `SecurityError` exception.
* Service Worker: attempts to create a new `ServiceWorker` will throw a `SecurityError` exception.

DOM Cache:

* Calls to `CacheStorage` will always reject with a `SecurityError`.

Browser caches:

* The HTTP cache, the Image cache, and the Alternative Services (Alt-Svc) cache are all partitioned for tracking resources, such that each top-level origin will have a separate partition and tracking resources on different top-level origins will be cached separate from each other.

Network connections:

* TLS sessions will not be resumed using a session ticket when an HTTPS connection is made to an embedded third-party resource that is classified as a tracker.
* HTTP connection reuse by domains classified as trackers is limited to requests that occur under the same top-level origin. For example, a request for content from `tracker.example` on `news.example` will not reuse an HTTP connection with a request for content from `tracker.example` on `shopping.example` or with requests that occur when `tracker.example` is visited directly (i.e., as a first party).

HTTP Referrers

* The default Referrer Policy for third-party resources classified as trackers is set to `strict-origin-when-cross-origin`.
### What is not blocked by the policy?

1. This policy does not currently restrict third-party storage access for resources that are not classified as tracking resources. We may choose to apply additional restrictions to third-party storage access in the future.
2. The restrictions applied by the policy will not prevent third-party scripts classified as tracking resources from accessing storage in the main context of the page. These scripts can continue to use storage scoped to the top-level origin.
3. Origins classified as trackers will have access to their own storage when they are loaded in a first-party context.
4. Cross-origin resources loaded from the same eTLD+1 as the top-level context will still have access to their storage.
5. Origins normally classified as trackers will not be blocked if the top-level page origin is determined to be from the same organization as them.
Storage access grants
---------------------

In order to improve web compatibility and permit third-party integrations that require storage access, Firefox will grant storage access scoped to the first party for a particular third-party origin as described in this section. Currently, Firefox includes some web compatibility heuristics that grant storage access to third-party resources classified as trackers when a user interacts with those third parties. We do this when we expect that not granting access would cause the web page to break. We also support an initial implementation of the Storage Access API, through which embedded `<iframe>`s can request storage access by calling `Document.requestStorageAccess()`. Although both of these approaches provide the same level of storage access, we recommend third parties switch to using the Storage Access API in order to guarantee their access to storage.

### Automatic storage access upon interaction

In order to improve web compatibility, Firefox currently includes some heuristics to grant storage access automatically to third parties that receive user interaction. These heuristics are intended to allow some third-party integrations that are common on the web to continue to function. They are intended to be temporary and will be removed in a future version of Firefox. They should not be relied upon for current and future web development.

Third-party storage access may be granted to resources that have been classified as tracking resources when a user gesture triggers a pop-up window that has opener access to the originating document. When that occurs, there are three possible ways a third-party origin can be granted access:

* The origin of the resource that is initially loaded in the pop-up window is granted storage access on the opener document if that origin has received user interaction as a first party within the past 30 days.
* After the initial resource is loaded in the pop-up window, the window may go through a series of redirects to other hosts. If a user interacts with the pop-up window following a redirect, the origin of the content loaded in the pop-up window is given storage access on the opener document.
* When there is a top-level redirect from a tracking origin to a non-tracking origin, the tracking origin receives short-lived storage access on the non-tracking origin and any other non-tracking origins that appear further down the redirect chain (i.e., if the load continues to redirect). The tracking origin must have received user interaction as a first party within the past 30 days, and the storage access permission expires after 15 minutes.
### Scope of storage access

When storage access is granted, it is scoped to the site of the opener document or subdomains of that origin. Access that is granted on the subdomain of an origin does extend to the top-level origin. As an example, if a resource from `tracker.example` is granted storage access on `foo.example.com`, then `tracker.example` will be able to access its cookies on `bar.foo.example.com` and on `example.com`.

When storage access is granted to `tracker.example` on `example.com`, all resources loaded from `tracker.example` on any top-level document loaded from `example.com` are immediately given storage access. This includes all resources loaded in the main context of the page, embedded `<iframe>`s, and resources loaded within embedded `<iframe>`s. Storage access is not extended to other resources loaded on `example.com` (e.g. `other-tracker.example`), nor to other first parties on which `tracker.example` is embedded (e.g. `example.org`).

Storage access grants extend into the first level of nested contexts, but no further. This means that `<iframe>`s embedded in the main context of the page and loaded from a domain classified as a tracker will have full access to all storage locations accessible through JavaScript. Similarly, requests for resources loaded in `<iframe>`s embedded in the main context of the page will have access to HTTP cookies. However, further nested contexts, including but not limited to those from the origin classified as a tracker, will not be granted storage access.

Consider the following embedding scenarios on a top-level page loaded from `example.com` on which `tracker.example` has been granted storage access.

| Embedding | tracker.example resource storage access |
| --- | --- |
| An image is loaded from `tracker.example` and embedded in the main context of `example.com`. | HTTP: Yes JS: N/A |
| `example.com` embeds an `<iframe>` from `example.org`. That `<iframe>` goes on to load an image from `tracker.example`. | HTTP: Yes JS: N/A |
| `example.com` embeds an `<iframe>` from `example.org`. That `<iframe>` goes on to embed an `<iframe>` from `tracker.example`. | HTTP: Yes JS: No |
| `example.com` embeds an `<iframe>` from `tracker.example`. | HTTP: Yes JS: Yes |
| `example.com` embeds an `<iframe>` from `example.com` (same origin). The nested `<iframe>` embeds an `<iframe>` from `tracker.example`. | HTTP: Yes JS: No |

### Storage access expiration

The storage access grant expires after 30 days. Domains classified as tracking resources may be granted third-party storage access on multiple first parties, and the storage permission for each party expires independently. The above heuristics will also serve to extend the lifetime of a third-party storage permission on origins that have already been granted access. Each time the heuristic is activated, or a success call to the Storage Access API is made, the pre-existing storage access expiration will be extended by 30 days, counting from the time the previous access was granted.

Please note that in the future we expect to make changes to how long storage access will remain valid for. As mentioned before, the way to know that you will be able to use storage as a third-party going forward will be using the Storage Access API.

Debugging
---------

We encourage site owners to test their sites, particularly those that rely on third-party content integrations. We've added several new features to Firefox to make testing easier.

### Developer Tools notifications

The Network Monitor in Firefox Developer Tools now includes an indicator for all resource requests that have been classified as tracking resources. This indicator is shown as a shield icon in the domain column. In the sample image below, `trackertest.org` is classified as a tracking resource, while the request to example.com is not.

![network requests in Firefox devtools indicating which ones are tracking resources with a small shield icon](/en-US/docs/Web/Privacy/Storage_Access_Policy/screen_shot_2018-09-21_at_10.34.22_am.png)

### Adding custom domains to the Tracking Protection list

Curious how things will work if a third-party domain on your site were classified as a tracker? We've added a preference that allows you to add custom domains to the Tracking Protection URL classifier. To do so:

1. Type `about:config` in your address bar. If you are presented with a page that warns you "This may void your warranty!", click "I accept the risk!"
2. Search for the preference name "urlclassifier.trackingAnnotationTable.testEntries".
3. If the preference already exists, edit the preference value.
4. If the preference does not exist, click "String" and then "+" to create a new preference.
5. For the preference value enter comma separated origins that you'd like to have classified as trackers. E.g. "example.net,example.org".

**Warning:** Be sure to remove these entries after you have finished testing.

FAQ
---

This cookie policy has the potential to lead to site breakage, but has been designed to allow common third-party integrations to continue to work while preventing cross-site tracking. In this section we describe the functionality you can expect in different integration scenarios.

### Will this storage access policy block ads from displaying on my website?

No — this feature only restricts access to cookies and site data that can be used to track users across websites. Blocking tracking identifiers does not prevent the display of advertisements.

### I use a third-party analytics service that is classified as a tracker. Will I still receive analytics data?

This depends on how the third-party analytics service is implemented. Third-party analytics providers will no longer be able to user their third-party storage to collect data. This means that providers using cookies which are scoped to their third-party domain, or local storage and other site data stored under their origin, will no longer have access to those identifiers across other websites.

If these services are embedded into the main context of the page, they can continue to use first-party cookies and site storage to track users across page visits on that specific first-party domain.

### I use third-party services for social login, like, and share button integration. Will my users still be able to make use of these services?

This depends on how the social integration is implemented. We expect that many of the popular social integrations will continue to function as they do under Firefox's current cookie policy with some minor differences in the user experience.

A social content provider that is classified as a tracker will not have access to their third-party cookies when the user first visits a new first party. Thus, the user may appear logged out to the service despite being logged in when they visit the provider's website directly. Depending on the type of integration, the user may have to take some action to interact with the social content provider before the provider is given access to their cookies. For example:

* For social login, the user may have to click a login button on the first party.
* For social like or share buttons, the user will have to first interact with the button in a logged-out state. Once they do, many social content providers will prompt them to log in.

After these interactions, the provider will receive third-party storage access if they prompt the user in a way that is captured by the storage access activation heuristics described above. These providers should consider switching to explicitly request storage access through the Storage Access API as soon as possible. An initial implementation of this API is currently available in Nightly.

### I use third-party pixels and other tools to measure the effectiveness of my ad campaigns. Will I still be able to measure the conversion rate of my ads?

This depends on how the third party has implemented the measurement tool, but generally ad conversion measurement will be more difficult. Consider the following examples:

1. You run an ad on a social media website that is seen several times by a user, but never clicked. That user later visits your website, which includes a conversion tracking tag from the same social media website. This type of conversion is often referred to as a "view-through conversion." Since the social media website does not have access to their third-party storage, they will not recognize the user as the same user that saw the advertisements on their website and the conversion will not be tracked. We expect that most view-through conversion tracking techniques will no longer work, including those offered by display networks.
2. You run an ad on a display network or social media website that is clicked by a user. That user lands on your website, which includes a conversion tracking tag from the same website that displayed your ad. This type of conversion is often referred to as a "click-through conversion." Since the social media site or display network will not have access to their third-party storage, they will not recognize the user as the same user that saw the advertisements on their website and the conversion will not be tracked. We expect that this version of click-through conversion will no longer work.
3. You run an ad that appears on a social media website. A user clicks on your advertisement and is taken to a landing page that contains a conversion tracking tag from the third-party network. On the social media website, the network annotates the advertisement landing page URL with a query parameter that signals that the visit was the result of a click on an advertisement. On your website, the display network's tag checks the URL query parameters and saves any ad tracking parameters to first-party storage. If a user later completes a conversion event, the network's tag checks first-party storage to determine which click (or clicks) was responsible for the visit. We expect that click-through conversion implemented in this way will continue to work.


State Partitioning - Privacy on the web

State Partitioning
==================

 State Partitioning is a broad effort to rework how Firefox manages client-side
 state (i.e., data stored in the browser) to mitigate the ability of websites
 to abuse state for cross-site tracking. This effort aims to
 achieve that by providing what is effectively a "different", isolated storage
 location to every website a user visits. This article gives an overview of
 the mechanism, lists the affected APIs and explains how to debug affected
 sites.

 State Partitioning is currently turned on by default in the Firefox Nightly
 channel. A subset of the state partitioning efforts (namely network partitioning) has been enabled by default in the release channel
 of Firefox since version 85.

Motivation
----------

### Cross-site tracking using shared state

 Browsers traditionally key client-side state by the origin (or sometimes
 registrable domain) of the location a resource was loaded from. For example,
 the cookies, localStorage objects, and caches available to an iframe loaded
 from `https://example.com/hello.html` will be keyed by
 `example.com`. This is true regardless of whether the browser
 is currently loading resources from that domain as a *first-party*
 resources or as an embedded *third party* resources. Trackers have taken
 advantage of this cross-site state to store user identifiers and access them
 across websites. The example below shows how `example.com` can use
 its cross-site state (in this instance, cookies) to track a user across its
 own site as well as `A.example` and `B.example`.

![An example of cross-site state](/en-US/docs/Web/Privacy/State_Partitioning/example-cross-site-state.png)

### Past approaches to blocking cross-site tracking

 Firefox's past cookie policies attempt to mitigate tracking by blocking
 access to some storage APIs (e.g., cookies and localStorage) for certain
 domains under certain conditions. For example, our "block all third-party
 cookies" policy will prevent all domains from accessing certain storage APIs
 when loaded in a third-party context. Our current
 default cookie policy blocks access in a third-party context only for domains classified as
 trackers.

State partitioning
------------------

 State Partitioning is a different approach to preventing cross-site tracking.
 Rather than block access to certain stateful APIs in a third-party context,
 Firefox provides embedded resources with a separate storage
 bucket for every top-level website. More specifically, Firefox double-keys
 all client-side state by the
 *origin*
 of the resource being loaded and by the *top-level
site*.
 In most instances, the top-level site is the scheme and eTLD+1 of the top-level
 page being visited by the user.

 In the example below `example.com` is embedded in
 `A.example` and `B.example`. However, since storage is
 partitioned, there are three distinct storage buckets (instead of one). The
 tracker can still access storage, but since every storage bucket is
 additionally keyed under the top-level site, the data it has access to on A
 will be different from the data on B. This will prevent a tracker from storing
 an identifier in their cookies when visited directly and then retrieving that
 identifier when embedded in other websites.

![An example of state partitioning](/en-US/docs/Web/Privacy/State_Partitioning/example-state-partitioning.png)

### Standardization

 The Privacy Community Group has a Work Item for
 Client-Side Storage Partitioning. This serves as an overview of the
 standardization efforts for storage partitioning in the individual standards
 affected. We intend to align our state partitioning implementation with these
 efforts as the Work Item is standardized.

### Status of partitioning in Firefox

* **Network Partitioning**: Enabled by default for all users since Firefox 85.
* **Dynamic State Partitioning**:
    + Since Firefox 86: Enabled for users that have
     "Strict" privacy protections enabled.
    + Since Firefox 90: Enabled in private browsing.
### Static partitioning

#### Storage partitioning

 To prevent JavaScript-accessible storage APIs from being used for cross-site
 tracking, accessible storage is partitioned by top-level site. This
 mechanism means that, generally, a third-party embedded in one top-level site
 cannot access data stored under another top-level site.

#### Storage APIs

* localStorage
* sessionStorage
* DOM Cache
* IndexedDB
* Broadcast Channel
* Shared Workers
* Service Workers

#### Network partitioning

 Networking-related APIs are not intended to be used for websites to store
 data, but they can be
 abused
 for cross-site tracking. As such, the following network APIs and caches are
 **permanently** partitioned by the top-level site.

**Note:** Network Partitioning is permanent. Websites can't
 control or relax these restrictions.

#### Network APIs

* HTTP Cache
* Image Cache
* Favicon Cache
* Connection Pooling
* Stylesheet Cache
* DNS
* HTTP Authentication
* Alt-Svc
* Speculative Connections
* Fonts & Font Cache
* HSTS
* OCSP
* Intermediate CA Cache
* TLS Client Certificates
* TLS Session Identifiers
* Prefetch
* Preconnect
* CORS-preflight Cache
* WebRTC deviceID
### Dynamic partitioning

 Generally, if accessible storage is partitioned by top-level site, access to a third-parties unpartitioned cookies
 can still be granted if the Storage Access API is supported:

* using the Storage Access API.
* automatically, such as for third-parties providing federated login.

 Details about automatic grants are provided in the
 Storage Access Heuristics section.

#### Dynamically-partitioned APIs

* Cookies

#### Storage access heuristics

 To improve web compatibility, Firefox currently includes some heuristics to
 grant unpartitioned access to cookies automatically to third parties that
 receive user interaction. These heuristics are intended to allow some
 third-party integrations that are common on the web to continue to function.

**Warning:** Storage access heuristics are a transitional
 feature meant to prevent website breakage. They should not be relied upon
 for current and future web development.

##### Opener Heuristics

* When a partitioned third-party opens a pop-up window that has
 opener access to the
 originating document, the third-party is granted storage access to its
 embedder for 30 days.
* When a first-party `a.example` opens a third-party pop-up
 `b.example`, `b.example` is granted
 third-party storage access to `a.example` for 30 days.

**Note:** For third-parties which abuse these heuristic for
 tracking purposes, we may require user interaction with the popup before
 storage access is granted.

##### Redirect Heuristics

* If a site `b.example` redirects to `a.example`, then
 `b.example` receives storage access to its embedder
 `a.example` if both `a.example` and
 `b.example` have been visited and interacted with within the
 last 10 minutes. This storage access will be granted for 15 minutes.
* If a tracker `tracker.example` (as classified by the Enhanced
 Tracking Protection) redirects to a non-tracker
 `a.example` and `tracker.example` received user
 interaction as a first-party within the last 45 days,
 `tracker.example` is granted storage access to
 `a.example` for 15 minutes.

#### Storage Access API

 Third-party frames may use
 document.requestStorageAccess to request unpartitioned access to cookie through the
 Storage Access API. Once
 granted, the requesting party will gain access to its entire first-party cookies (i.e., the cookies it would have access to if visited as a first-party).

**Warning:** When storage access is granted there may still
 be references to the partitioned storage. However, sites shouldn't rely on
 being able to use partitioned and unpartitioned cookies at the same
 time.

### Debugging

 We encourage site owners to test their sites, particularly those that rely on
 third-party content integrations. There are several features in Firefox to
 make testing easier.

#### Logging

 Here is an overview of the messages logged to the web console when interacting
 with storage in a third-party context. In the following examples,
 `a.example` is the top-level site which embeds the third-party frame
 `b.example`.

| Reason | Console Message |
| --- | --- |
| Storage of a third-party frame is partitioned | Partitioned cookie or storage access was provided to "b.example" because it is loaded in the third-party context and storage partitioning is enabled. |
| Access to unpartitioned cookies is granted through Storage access heuristics | Storage access automatically granted for First-Party isolation "b.example" on "a.example". |
| Access to unpartitioned cookies is granted via the StorageAccessAPI | Storage access granted for origin "b.example" on "a.example". |

#### Clear third-party storage-access

 If a third-party iframe is granted storage access to the parent context,
 Firefox sets a permission. To revoke access you can clear the permission via
 the Site Information Panel in the permissions section under "Cross-site Cookies".

#### Test Preferences

**Warning:** Make sure to set these preferences in a separate
 Firefox profile or reset them after testing.

##### Disable Web Compatibility Features

 Setting `privacy.antitracking.enableWebcompat` to `false` will **disable** all
 ETP and State Partitioning web-compatibility features. Disabling these features
 can be useful when testing, to ensure your website is fully compatible with the
 State Partitioning mechanism in Firefox, and it does not rely on temporary
 heuristics.

Features disabled by the pref include:

* Storage access heuristics: Unpartitioned
 access to cookies can only be acquired via the Storage Access API.
* Automatic storage access grants:
 document.requestStorageAccess
 will always prompt the user.
* SmartBlock's "unblock on opt-in" feature, which
 will allow certain trackers when users interact with them.
* Any temporary anti-tracking exceptions
 granted to websites via the skip-listing mechanism.

##### Disable Heuristics

 The following preferences can be used to disable individual storage access
 heuristics via the
 config editor:

* Enable / disable the redirect heuristics:
 `privacy.restrict3rdpartystorage.heuristic.recently_visited`,
 `privacy.restrict3rdpartystorage.heuristic.redirect`
* Enable / disable the window open heuristics:
 `privacy.restrict3rdpartystorage.heuristic.window_open`,
 `privacy.restrict3rdpartystorage.heuristic.opened_window_after_interaction`

##### Disable Network Partitioning

 Network partitioning can be disabled with the
 `privacy.partition.network_state` pref.

##### Disable Dynamic State Partitioning

 To disable dynamic storage partitioning for all sites you can use the
 `network.cookie.cookieBehavior` pref:

| Value | Description |
| --- | --- |
| 5 | Reject (known) trackers and partition third-party storage. |
| 4 | Only reject trackers (Storage partitioning disabled). |
| 0 | Allow all |

##### Exempt specific origins from partitioning

 Dynamic State Partitioning can also be disabled for specific
 origins with the `privacy.restrict3rdpartystorage.skip_list`
 preference. This pref holds a comma separated list of origins to exempt.
 The pref value should follow the following format
 `first-party_origin_1,third-party_origin_1;first-party_origin_2,third-party_origin_2;...`.

 For example, to disable partitioning for `tracker.example`
 on `example.com` and for `social.example` on
 `news.example`, you would set the pref to the following:
```

https://tracker.example,http://example.com;https://social.example,https://news.example
```


Redirect tracking protection - Privacy on the web

Redirect tracking protection
============================

Firefox 79 includes protection against redirect tracking. This document describes how the protections work.

Redirect tracking defined
-------------------------

**Redirect tracking** is an abuse of cross-site navigation in which a tracker momentarily redirects a user to their website for the purpose of using first-party storage to track that user across websites.

Cross-site navigations are a core feature of the web; a person might search for "best running shoes" on a search engine, click a search result to read reviews, and finally click a link to buy a pair of shoes from an online store. In the past, each of these websites could embed resources from the same tracker, and the tracker could use its cookies to link all of these page visits to the same person. To protect the privacy of Firefox users, Enhanced Tracking Protection (ETP) already blocks trackers from using cookies when they are embedded in a third-party context, but still allows them to use cookies as a first party because blocking first party cookies causes websites to break. Redirect tracking takes advantage of this to circumvent third-party cookie blocking.

Redirect trackers work by forcing you to make an imperceptible and momentary stopover to their website as part of that journey. So instead of navigating directly from the review website to the retailer, you'll end up navigating to the redirect tracker first rather than to the retailer. This means that the tracker is loaded as a first party. The redirect tracker associates tracking data with the identifiers they have stored in their first-party cookies and then forwards you to the retailer.

Redirect tracking protection explained
--------------------------------------

To protect against redirect tracking Firefox periodically clears cookies and site data from trackers. We only clear this data from storage if the user is blocking tracking cookies (i.e., the `network.cookie.cookieBehavior` pref is set to `4`). Support for other cookie policies is tracked by Bug 1643045.

### What origins are cleared?

An origin will be cleared if it fulfills the following conditions:

1. It has stored cookies or accessed other site storage (e.g. localStorage, IndexedDB, or the Cache API) within the last 72 hours. Since cookies are per-host, we will clear both the `http` and `https` origin variants of a cookie host.
2. The origin is classified as a tracker in our Tracking Protection list.
3. No origin with the same base domain (eTLD+1) has a user-interaction permission.
    * This permission is granted to an origin for 45 days once a user interacts with a top-level document from that origin. "Interacting" includes scrolling.
    * Although this permission is stored on a per-origin level, we will check whether any origin with the same base domain has it, to avoid breaking sites with subdomains and a corresponding cookie setup.
### What data is cleared?

Firefox will clear the following data:

* Network cache and image cache
* Cookies
* AppCache
* DOM Quota Storage (localStorage, IndexedDB, ServiceWorkers, DOM Cache, etc.)
* DOM Push notifications
* Reporting API Reports
* Security Settings (i.e. HSTS)
* EME Media Plugin Data
* Plugin Data (e.g. Flash)
* Media Devices
* Storage Access permissions granted to the origin
* HTTP Authentication Tokens
* HTTP Authentication Cache

**Note:** Even though we're clearing all of this data, we currently only flag origins for clearing when they use cookies or other site storage.

Storage clearing ignores origin attributes. This means that storage will be cleared across containers and isolated storage (i.e. from First-Party Isolation).

### How frequently is data cleared?

Firefox clears storage based on the firing of an internal event called `idle-daily`, which is defined by the following conditions:

* It will, at the earliest, fire 24h after the last `idle-daily` event fired.
* It will only fire if the user has been idle for at least 3min (for 24-48h after the last `idle-daily`) or 1min (for >48h after the last `idle-daily`).

This means that there are at least 24 hours between each storage clearance, and storage will only be cleared when the browser is idle. When clearing cookies, we sort cookies by creation date and batch them into sets of 100 (controlled by the pref `privacy.purge_trackers.max_purge_count`) for performance reasons.

Debugging
---------

Redirect tracking protection can be enabled or disabled by flipping the `privacy.purge_trackers.enabled` preference in `about:config`. Furthermore, it will only run if the `network.cookie.cookieBehavior` pref is set to `4` or `5` in Firefox 79+ onwards (`1`, `3`, `4`, or `5` as of Firefox 80).

Different log levels can be set via the `privacy.purge_trackers.logging.level` pref.

For debugging purposes, it's easiest to trigger storage clearing by triggering the service directly via the Browser Console command line. Note that this is different from the normal Web Console you might use to debug a website, and requires the `devtools.chrome.enabled` pref to be set to `true` to use it interactively. Once you've enabled the Browser Console you can trigger storage clearing by running the following command:

```js
await Components.classes["@mozilla.org/purge-tracker-service;1"]
  .getService(Components.interfaces.nsIPurgeTrackerService)
  .purgeTrackingCookieJars();
```

The time until user interaction permissions expire can be set to a lower amount using the `privacy.userInteraction.expiration` pref. Note that you will have to set this pref before visiting the sites you want to test — it will not apply retroactively.

Other implementations
---------------------

WebKit first shipped redirect tracking protection in ITP 2.0 (they refer to the same attack as bounce tracking). As of July 2020, there are several significant differences between WebKit's implementation and Firefox's implementation:

* The list of origins to be cleared in Firefox is based on our tracking protection list; WebKit relies on ITP's classification.
* Firefox's definition of "interaction" includes user scrolling when visiting the origin as a first party; WebKit's does not.
* Firefox will not clear data for an origin if it has received interaction as a first party in the last 45 days of calendar time; WebKit's interaction window is 30 days of browser use (e.g. days in which the user has had at least one interaction with Safari).


Partitioned: All third-party storage access requests - Privacy on the web

Partitioned: All third-party storage access requests
====================================================

Message
-------

Firefox:
```

CookiePartitionedForeign=Partitioned cookie
or storage access was provided to "<URL>" because it is loaded in the
third-party context and storage partitioning is enabled.
```

What went wrong?
----------------

 A request to access cookies or storage was *partitioned* because it
 came from a third-party (a different origin) and
 dynamic state partitioning is enabled.

 With Dynamic State Partitioning enabled, Firefox provides embedded resources with a
 separate storage bucket for every top-level website. Embedded third-parties may
 request access to the top-level storage bucket via the Storage Access API.
 You can also disable Dynamic State Partitioning with the
 `network.cookie.cookieBehavior` pref.

See also
--------

* State Partitioning


Blocked: Custom cookie permission - Privacy on the web

Blocked: Custom cookie permission
=================================

Message
-------

Firefox:
```

CookieBlockedByPermission=Request to access cookies or storage on "X" was blocked because of custom cookie permission.
```

What went wrong?
----------------

A request to access cookies or storage was blocked because there's a custom user-defined permission set.

The permission can be changed or removed by:

* Going to *Preferences > Content Blocking > Cookies and Site Data*
* Clicking on the *Manage Permissions* button and updating the listed exceptions
See also
--------

* Content blocking on support.mozilla.org


Blocked: All third-party storage access requests - Privacy on the web

Blocked: All third-party storage access requests
================================================

Message
-------

Firefox:
```

CookieBlockedForeign=Request to access cookies or storage on "X" was blocked because we are blocking all third-party storage access requests and content blocking is enabled.
```

What went wrong?
----------------

A request to access cookies or storage was blocked because it came from a third-party (a different origin) and content blocking is enabled.

The permission can be changed or removed by:

* Going to *Preferences > Content Blocking* and either
* adding an exception with the *Manage Exceptions*… button
* choosing the *Custom* Content Blocking and unchecking the *Cookies* checkbox

If the resource that is being blocked doesn't need authentication, you can fix the warning message by adding a `crossorigin="anonymous"` attribute to the relevant element.

See also
--------

* Content blocking on support.mozilla.org
* The `crossorigin` attribute


Blocked: All storage access requests - Privacy on the web

Blocked: All storage access requests
====================================

Message
-------

Firefox:
```

CookieBlockedAll=Request to access cookies or storage on "X" was blocked because we are blocking all storage access requests.
```

What went wrong?
----------------

A request to access cookies or storage was blocked because the browser is blocking all storage access.

The permission can be changed or removed by:

* Going to *Preferences > Content Blocking*
* In the *Custom* Content Blocking section, selecting a value other than *All Cookies* for the *Cookies* item

If the resource that is being blocked doesn't need authentication, you can fix the warning message by adding a `crossorigin="anonymous"` attribute to your element.

See also
--------

* Content blocking on support.mozilla.org
* The `crossorigin` attribute


Blocked: Storage access requests from trackers - Privacy on the web

Blocked: Storage access requests from trackers
==============================================

Message
-------

Firefox:
```

Request to access cookie or storage on “X” was blocked because it came from a tracker and content blocking is enabled.
```

What went wrong?
----------------

A request to access cookies or storage was blocked because the browser identified it as coming from a tracker and content blocking is enabled.

The permission can be changed or removed by:

* Going to *Preferences > Privacy & Security > Enhanced Tracking Protection* and either
    + adding an exception with the *Manage Exceptions*… button
    + choosing the *Custom* Content Blocking and unchecking the *Tracker* checkbox

If the blocked resource doesn't need authentication, you can fix the warning message by adding a `crossorigin="anonymous"` attribute to the relevant element.

See also
--------

* Enhanced Tracking Protection in Firefox for desktop on support.mozilla.org
* The `crossorigin` attribute


Errors - Privacy on the web

Errors
======

This page lists the errors that can be raised due to Firefox's anti-tracking functionality, governed by the Storage Access Policy. You can find further information about them by clicking on the links below:

A request to access cookies or storage was

* blocked because of a custom cookie permission
* blocked because it came from a tracker and content blocking is enabled
* blocked because we are blocking all storage access requests
* blocked because we are blocking all third-party storage access requests and content blocking is enabled
* granted *partitioned* access because it came from a third-party and dynamic state partitioning is enabled


Block formatting context - Developer guides

Block formatting context
========================

A **block formatting context** (BFC) is a part of a visual CSS rendering of a web page. It's the region in which the layout of block boxes occurs and in which floats interact with other elements.

A block formatting context is created by at least one of the following:

* The root element of the document (`<html>`).
* Floats (elements where `float` isn't `none`).
* Absolutely positioned elements (elements where `position` is `absolute` or `fixed`).
* Inline-blocks (elements with `display``: inline-block`).
* Table cells (elements with `display``: table-cell`, which is the default for HTML table cells).
* Table captions (elements with `display``: table-caption`, which is the default for HTML table captions).
* Anonymous table cells implicitly created by the elements with `display``: table`, `table-row`, `table-row-group`, `table-header-group`, `table-footer-group` (which is the default for HTML tables, table rows, table bodies, table headers, and table footers, respectively), or `inline-table`.
* Block elements where `overflow` has a value other than `visible` and `clip`.
* `display``: flow-root`.
* Elements with `contain``: layout`, `content`, or `paint`.
* Flex items (direct children of the element with `display``: flex` or `inline-flex`) if they are neither flex nor grid nor table containers themselves.
* Grid items (direct children of the element with `display``: grid` or `inline-grid`) if they are neither flex nor grid nor table containers themselves.
* Multicol containers (elements where `column-count` or `column-width` isn't `auto`, including elements with `column-count: 1`).
* `column-span``: all` should always create a new formatting context, even when the `column-span: all` element isn't contained by a multicol container (Spec change, Chrome bug).

Formatting contexts affect layout, but typically, we create a new block formatting context for the positioning and clearing floats rather than changing the layout, because an element that establishes a new block formatting context will:

* contain internal floats.
* exclude external floats.
* suppress margin collapsing.

**Note:** A Flex/Grid container(`display`: flex/grid/inline-flex/inline-grid) establishes a new Flex/Grid formatting context, which is similar to block formatting context except layout. There's no floating children available inside a flex/grid container, but exclude external floats and suppress margin collapsing still works.

Examples
--------

### Contain internal floats

Make float content and alongside content the same height.

Let's have a look at a couple of these in order to see the effect creating a new BFC.

In the following example, we have a floated element inside a `<div>` with a `border` applied. The content of that `<div>` has floated alongside the floated element. As the content of the float is taller than the content alongside it, the border of the `<div>` now runs through the float. As explained in the guide to in-flow and out of flow elements, the float has been taken out of flow so the `background` and `border` of the `<div>` only contain the content and not the float.

**using `overflow: auto`**

Setting `overflow: auto` or set other values than the initial value of `overflow: visible` created a new BFC containing the float. Our `<div>` now becomes a mini-layout inside our layout. Any child element will be contained inside it.

The problem with using `overflow` to create a new BFC is that the `overflow` property is meant for telling the browser how you want to deal with overflowing content. There are some occasions in which you will find you get unwanted scrollbars or clipped shadows when you use this property purely to create a BFC. In addition, it is potentially not readable for a future developer, as it might not be obvious why you used `overflow` for this purpose. If you use `overflow`, it is a good idea to comment the code to explain.

**using `display: flow-root`**

A newer value of `display` lets us create a new BFC without any other potentially problematic side-effects. Using `display: flow-root` on the containing block creates a new BFC .

With `display: flow-root;` on the `<div>`, everything inside that container participates in the block formatting context of that container, and floats will not poke out of the bottom of the element.

The value name of `flow-root` makes sense when you understand you are creating something that acts like the `root` element (`<html>` element in browser) in terms of how it creates a new context for the flow layout inside it.

#### HTML

```html
<section>
  <div class="box">
    <div class="float">I am a floated box!</div>
    <p>I am content inside the container.</p>
  </div>
</section>
<section>
  <div class="box" style="overflow:auto">
    <div class="float">I am a floated box!</div>
    <p>I am content inside the <code>overflow:auto</code> container.</p>
  </div>
</section>
<section>
  <div class="box" style="display:flow-root">
    <div class="float">I am a floated box!</div>
    <p>I am content inside the <code>display:flow-root</code> container.</p>
  </div>
</section>
```

#### CSS

```css
section {
  height: 150px;
}
.box {
  background-color: rgb(224 206 247);
  border: 5px solid rebeccapurple;
}
.box[style] {
  background-color: aliceblue;
  border: 5px solid steelblue;
}
.float {
  float: left;
  width: 200px;
  height: 100px;
  background-color: rgb(255 255 255 / 50%);
  border: 1px solid black;
  padding: 10px;
}
```

### Exclude external floats

In the following example, we are using `display:flow-root` and floats to implement double columns layout. We are able to do this because an element in the normal flow that establishes a new BFC does not overlap the margin box of any floats in the same block formatting context as the element itself.

#### HTML

```html
<section>
  <div class="float">Try to resize this outer float</div>
  <div class="box"><p>Normal</p></div>
</section>
<section>
  <div class="float">Try to resize this outer float</div>
  <div class="box" style="display:flow-root">
    <p><code>display:flow-root</code></p>
  </div>
</section>
```

#### CSS

```css
section {
  height: 150px;
}
.box {
  background-color: rgb(224 206 247);
  border: 5px solid rebeccapurple;
}
.box[style] {
  background-color: aliceblue;
  border: 5px solid steelblue;
}
.float {
  float: left;
  overflow: hidden; /\* required by resize:both \*/
  resize: both;
  margin-right: 25px;
  width: 200px;
  height: 100px;
  background-color: rgb(255 255 255 / 75%);
  border: 1px solid black;
  padding: 10px;
}
```

Rather than inline-blocks with width:<percentage>, in this case we don't have to specify the width of the right div.

Note that flexbox is a more efficient way to implement multi-column layout in modern CSS.

### Prevent margin collapsing

You can create a new BFC to avoid margin collapsing between two neighbor elements.

#### Margin collapsing example

In this example we have two adjacent `<div>` elements, which each have a vertical margin of `10px`. Because of margin collapsing, the vertical gap between them is 10 pixels, not the 20 we might expect.

```html
<div class="blue"></div>
<div class="red"></div>
```

```css
.blue,
.red {
  height: 50px;
  margin: 10px 0;
}

.blue {
  background: blue;
}

.red {
  background: red;
}
```

#### Preventing margin collapsing

In this example we wrap the second `<div>` in an outer one, to create a new BFC and prevent margin collapsing.

```html
<div class="blue"></div>
<div class="outer">
  <div class="red"></div>
</div>
```

```css
.blue,
.red {
  height: 50px;
  margin: 10px 0;
}

.blue {
  background: blue;
}

.red {
  background: red;
}

.outer {
  overflow: hidden;
  background: transparent;
}
```

Specifications
--------------

| Specification |
| --- |
| CSS Display Module Level 3 # block-formatting-context |

See also
--------

* `float`, `clear`
* CSS key concepts:
    + CSS syntax
    + At-rules
    + Comments
    + Specificity
    + Inheritance
    + Box model
    + Layout modes
    + Visual formatting models
    + Margin collapsing
    + Values
        - Initial values
        - Computed values
        - Used values
        - Actual values
    + Value definition syntax
    + Shorthand properties
    + Replaced elements


CSS Layout - Developer guides

CSS Layout
==========

There are a number of methods that you can use to lay out your web pages and applications. MDN contains a number of in-depth guides to the different methods, and this page provides an overview of them all.

Normal flow, block, and inline layout
-------------------------------------

If you are not using a flex or grid layout, then your content is laid out using normal flow, or block and inline layout. These guides will help you to understand the way this layout method works.

Block and Inline layout in normal flow

An introduction to normal flow.

In flow and Out of flow

How to take an item out of flow, and what that does to the layout of your document.

Formatting contexts explained

An introduction to creating a new formatting context.

Flow layout and writing modes

How flow layout works if you use a different writing mode, such as vertical text.

Flow layout and overflow

Understanding and managing overflow.

Introduction to the CSS basic box model

Understanding the box model is a CSS fundamental; this guide explains how it works.

Mastering margin collapsing

Find out why you sometimes end up with less margin than you expect, due to margin collapsing in normal flow.

Understanding CSS z-index

Absolute positioning, flexbox, and grid all result in the stack (elements' relative position on the z-axis) to be manipulable via the `z-index` property. This article explains how to manage it.

Multi-column layout
-------------------

Multi-column layout, often referred to as multicol, takes content in normal flow, and breaks it into columns. Find out how to use this layout method in the following guides.

Basic concepts of Multicol

An overview of the basic functionality of multicol.

Styling columns

There is a limited amount of styling opportunities for columns; this guide explains what you can do.

Spanning and balancing

Spanning elements across columns, and balancing the content of columns.

Handling overflow in Multicol

What happens when there is more content than available column space?

Content breaks in Multicol

Dealing with content breaks as the content is split into columns.

Flexbox
-------

CSS Flexible Box Layout, commonly known as flexbox, is a layout model optimized for user interface design, and the layout of items in one dimension. In the flex layout model, the children of a flex container can be laid out in any direction, and can "flex" their sizes, either growing to fill unused space or shrinking to avoid overflowing the parent.

Basic Concepts of Flexbox

An overview of the features of Flexbox.

Relationship of Flexbox to other layout methods

How Flexbox relates to other layout methods, and other CSS specifications.

Aligning items in a flex container

How the Box Alignment properties work with Flexbox.

Ordering flex items

Explaining the different ways to change the order and direction of items, and covering the potential issues in doing so.

Controlling Ratios of flex items along the main axis

Explaining the `flex-grow`, `flex-shrink`, and `flex-basis` properties.

Mastering wrapping of flex items

How to create flex containers with multiple lines and control the display of the items along those lines.

Typical use cases of Flexbox

Common design patterns that are typical Flexbox use cases.

Grid layout
-----------

CSS Grid Layout introduces a two-dimensional grid system to CSS. Grids can be used to lay out major page areas or small user interface elements.

Basic concepts of Grid Layout

An overview of the features of grid layout.

Relationship of Grid Layout to other layout methods

How grid relates to other methods such as alignment, sizing, and flexbox.

Layout using line-based placement

How to place items by numbered lines.

Grid template areas

How to place items using the grid-template syntax.

Layout using named grid lines

How to name lines, and place items by line name rather than number.

Auto-placement in CSS Grid Layout

How to manage the auto-placement algorithm, and understand how the browser places items.

Box alignment in CSS Grid Layout

How to align items, and distribute space on both axes in grid.

CSS Grid, Logical Values and Writing Modes

How to use flow relative, rather than physical, properties and values with grid.

CSS Grid Layout and accessibility

Some accessibility considerations when working with grid layout.

CSS Grid and progressive enhancement

How to ensure your site still works well in browsers that don't support grid.

Realizing common layouts using CSS Grid

Using grid to build some common layouts.

Subgrid

An explanation of the subgrid value, part of Grid Level 2.

Masonry Layout
Experimental

An explanation of the masonry layout feature in Grid Level 3.

Alignment
---------

Box alignment in block layout

The alignment properties are specified for block and inline layout, though there is no browser support as yet.

Box alignment in flexbox

The alignment properties first appeared with flexbox; this guide explains how they work.

Box alignment in grid layout

How to align items in grid layout.

Box alignment in multi-column layout

How alignment will work in multicol.


Challenge solutions - Developer guides

Challenge solutions
===================

This page provides solutions to the challenges posed in the CSS Getting Started tutorial. These are not the only possible solutions. The sections below correspond to the titles of the tutorial sections.

Why use CSS
-----------

The challenges on page Why use CSS are:

### Colors

Challenge

Without looking up a reference, find five more color names that work in your stylesheet.

Solution

CSS supports common color names like `orange`, `yellow`, `blue`, `green`, or `black`. It also supports some more exotic color names like `chartreuse`, `fuschia`, or `burlywood`. See CSS Color value for a complete list as well as other ways of specifying colors.

How CSS works
-------------

The challenges on page How CSS works are:

### DOM inspector

Challenge

In DOMi, click on a STRONG node. Use DOMi's right-hand pane to find out where the node's color is set to red, and where its appearance is made bolder than normal text.

Solution

In the menu above the right-hand pane, choose **CSS Rules**. You see two items listed, one that references an internal resource and one that references your stylesheet file. The internal resource defines the **font-weight** property as `bolder`; your stylesheet defines the **color** property as `red`.

Cascading and inheritance
-------------------------

The challenges on page Cascading and inheritance are:

### Inherited styles

Challenge

Change your stylesheet so that only the red letters are underlined.

Solution

Move the declaration for underlining from the rule for `<p>` to the one for `<strong>`. The resulting file looks like this:

```css
p {
  color: blue;
}
strong {
  color: orange;
  text-decoration: underline;
}
```

Later sections of this tutorial describe style rules and declarations in greater detail.

Selectors
---------

The challenges on page Selectors are:

### Second paragraph blue

Challenge

Without changing your HTML file, add a single rule to your CSS file that keeps all the initial letters the same color as they are now, but makes all the other text in the second paragraph blue.

Solution

Add a rule with an ID selector of `#second` and a declaration `color: blue;`, as shown below:

```css
#second {
  color: blue;
}
```

A more specific selector, `p#second` also works.

### Both paragraphs blue

Challenge

Now change the rule you have just added (without changing anything else), to make the first paragraph blue too.

Solution

Change the selector of the new rule to be a tag selector using `p`:

```css
p {
  color: blue;
}
```

The rules for the other colors all have more specific selectors, so they override the blue of the paragraph.

Readable CSS
------------

### Commenting out a rule

Challenge

Comment out part of your stylesheet, without changing anything else, to make the very first letter of your document red.

Solution

One way to do this is to put comment delimiters around the rule for `.carrot`:

```css
/\*
.carrot {
 color: orange;
}
\*/
```

Text styles
-----------

### Big initial letters

Challenge

Without changing anything else, make all six initial letters twice the size in the browser's default serif font.

Solution

Add the following style declaration to the `strong` rule:

```css
font: 200% serif;
```

If you use separate declarations for `font-size` and `font-family`, then the `font-style` setting on the first paragraph is *not* overridden.

Color
-----

### Three-digit color codes

Challenge

In your CSS file, change all the color names to 3-digit color codes without affecting the result.

Solution

The following values are reasonable approximations of the named colors:

```css
strong {
  color: #f00; /\* red \*/
  background-color: #ddf; /\* pale blue \*/
  font: 200% serif;
}

.carrot {
  color: #fa0; /\* orange \*/
}

.spinach {
  color: #080; /\* dark green \*/
}

p {
  color: #00f; /\* blue \*/
}
```

Content
-------

The challenges on page are:

### Add an image

Challenge

Add a one rule to your stylesheet so that it displays the image at the start of each line.

Solution

Add this rule to your stylesheet:

```css
p::before {
  content: url("yellow-pin.png");
}
```

Lists
-----

The challenges on page Lists are:

### Lower Roman numerals

Challenge

Add a rule to your stylesheet, to number the oceans using Roman numerals from i to v.

Solution

Define a rule for list items to use the `lower-roman` list style:

```css
li {
  list-style: lower-roman;
}
```

### Capital letters

Challenge

Change your stylesheet to identify the headings with capital letters in parentheses.

Solution

Add a rule to the body element (parent of the headings) to reset a new counter, and one to display and increment the counter on the headings:

```css
/\* numbered headings \*/
body {
  counter-reset: headnum;
}
h3::before {
  content: "(" counter(headnum, upper-latin) ") ";
  counter-increment: headnum;
}
```

Boxes
-----

The challenges on page Boxes are:

### Ocean border

Challenge

Add one rule to your stylesheet, making a wide border all around the oceans in a color that reminds you of the sea.

Solution

The following rule achieves this effect:

```css
ul {
  border: 10px solid lightblue;
  width: 100px;
}
```

Layout
------

The challenges on page Layout are:

### Default image position

### Fixed image position

Challenge

Change your sample document, `doc2.html`, adding this tag to it near the end, just before `</BODY>`: `<IMG id="fixed-pin" src="Yellow-pin.png" alt="Yellow map pin">` Predict where the image will appear in your document. Then refresh your browser to see if you were correct.

Solution

 The image appears to the right of the second list.

 ![A list of five placeholder texts is titled Numbered Paragraphs. A yellow pin is placed to the right of a blue box containing the list.](/en-US/docs/Web/Guide/CSS/Getting_started/Challenge_solutions/pin_placement.png)

Challenge

Add a rule to your stylesheet that places the image in the top right of your document.

Solution

The following rule achieves the desired result:

```css
#fixed-pin {
  position: fixed;
  top: 3px;
  right: 3px;
}
```

Tables
------

The challenges on page Tables are:

### Borders on data cells only

Challenge

Change the stylesheet to make the table have a green border around only the data cells.

Solution

The following rule puts borders around only `<td>` elements that are inside the `<tbody>` element of the table with `id=demo-table`:

```css
#demo-table tbody td {
  border: 1px solid #7a7;
}
```

Media
-----

The challenges on page Media are:

### Separate print style file

Challenge

Move the print-specific style rules to a separate CSS file and import them into your `style4.css` stylesheet.

Solution

Cut and paste the lines between `/* print only */` and `/* end print only */` into a file named `style4_print.css`. In style4.css, add the following line at the beginning of the file:

```css
@import url("style4\_print.css") print;
```

### Heading hover color

Challenge

Make the headings turn blue when the mouse pointer is over them.

Solution

The following rule achieves the desired result:

```css
h1:hover {
  color: blue;
}
```

JavaScript
----------

### Move box to the right

Challenge

Change the script so that the square jumps to the right by 20 em when its color changes, and jumps back afterwards.

Solution

Add lines to modify the `margin-left` property. Be sure to specify it as `marginLeft` in JavaScript. The following script achieves the desired result:

```js
// JavaScript demonstration
function doDemo(button) {
  const square = document.getElementById("square");
  square.style.backgroundColor = "#fa4";
  square.style.marginLeft = "20em";
  button.setAttribute("disabled", "true");
  setTimeout(clearDemo, 2000, button);
}

function clearDemo(button) {
  const square = document.getElementById("square");
  square.style.backgroundColor = "transparent";
  square.style.marginLeft = "0em";
  button.removeAttribute("disabled");
}
```

SVG and CSS
-----------

### Change color of inner petals

Challenge

Change the stylesheet so that the inner petals all turn pink when the mouse pointer is over any one of them, without changing the way the outer petals work.

Solution

Move the position of the :hover pseudo-class from a specific petal, to all petals

```css
#inner-petals {
  --segment-fill-fill-hover: pink;
}

/\* Non-standard way for some older browsers \*/
#inner-petals:hover .segment-fill {
  fill: pink;
  stroke: none;
}
```


HTTP authentication - HTTP

HTTP authentication
===================

 HTTP provides a general framework for access control and authentication.
 This page is an introduction to the HTTP framework for authentication, and shows how to restrict access to your server using the HTTP "Basic" schema.

The general HTTP authentication framework
-----------------------------------------

RFC 7235 defines the HTTP authentication framework, which can be used by a server to challenge a client request, and by a client to provide authentication information.

The challenge and response flow works like this:

1. The server responds to a client with a `401` (Unauthorized) response status and provides information on how to authorize with a `WWW-Authenticate` response header containing at least one challenge.
2. A client that wants to authenticate itself with the server can then do so by including an `Authorization` request header with the credentials.
3. Usually a client will present a password prompt to the user and will then issue the request including the correct `Authorization` header.

![A sequence diagram illustrating HTTP messages between a client and a server lifeline.](/en-US/docs/Web/HTTP/Authentication/http-auth-sequence-diagram.png)

 The general message flow above is the same for most (if not all) authentication schemes.
 The actual information in the headers and the way it is encoded does change!

**Warning:** The "Basic" authentication scheme used in the diagram above sends the credentials encoded but not encrypted.
 This would be completely insecure unless the exchange was over a secure connection (HTTPS/TLS).

### Proxy authentication

 The same challenge and response mechanism can be used for *proxy authentication*.
 As both resource authentication and proxy authentication can coexist, a different set of headers and status codes is needed. In the case of proxies, the challenging status code is `407` (Proxy Authentication Required), the `Proxy-Authenticate` response header contains at least one challenge applicable to the proxy, and the `Proxy-Authorization` request header is used for providing the credentials to the proxy server.

### Access forbidden

If a (proxy) server receives *invalid* credentials, it should respond with a `401` `Unauthorized` or with a `407` `Proxy Authentication Required`, and the user may send a new request or replace the `Authorization` header field.

If a (proxy) server receives valid credentials that are *inadequate* to access a given resource, the server should respond with the `403` `Forbidden` status code. Unlike `401` `Unauthorized` or `407` `Proxy Authentication Required`, authentication is impossible for this user and browsers will not propose a new attempt.

In all cases, the server may prefer returning a `404` `Not Found` status code, to hide the existence of the page to a user without adequate privileges or not correctly authenticated.

### Authentication of cross-origin images

 A potential security hole (that has since been fixed in browsers) was authentication of cross-site images.
 From Firefox 59 onwards, image resources loaded from different origins to the current document are no longer able to trigger HTTP authentication dialogs (Firefox bug 1423146), preventing user credentials being stolen if attackers were able to embed an arbitrary image into a third-party page.

### Character encoding of HTTP authentication

Browsers use `utf-8` encoding for usernames and passwords.

Firefox once used `ISO-8859-1`, but changed to `utf-8` for parity with other browsers and to avoid potential problems as described in Firefox bug 1419658.

### WWW-Authenticate and Proxy-Authenticate headers

The `WWW-Authenticate` and `Proxy-Authenticate` response headers define the authentication method that should be used to gain access to a resource. They must specify which authentication scheme is used, so that the client that wishes to authorize knows how to provide the credentials.

The syntax for these headers is the following:

```http
WWW-Authenticate: <type> realm=<realm>
Proxy-Authenticate: <type> realm=<realm>
```

Here, `<type>` is the authentication scheme ("Basic" is the most common scheme and introduced below). The *realm* is used to describe the protected area or to indicate the scope of protection. This could be a message like "Access to the staging site" or similar, so that the user knows to which space they are trying to get access to.

### Authorization and Proxy-Authorization headers

The `Authorization` and `Proxy-Authorization` request headers contain the credentials to authenticate a user agent with a (proxy) server. Here, the `<type>` is needed again followed by the credentials, which can be encoded or encrypted depending on which authentication scheme is used.

```http
Authorization: <type> <credentials>
Proxy-Authorization: <type> <credentials>
```

Authentication schemes
----------------------

The general HTTP authentication framework is the base for a number of authentication schemes.

IANA maintains a list of authentication schemes, but there are other schemes offered by host services, such as Amazon AWS.

Some common authentication schemes include:

**Basic**

See RFC 7617, base64-encoded credentials. More information below.

**Bearer**

See RFC 6750, bearer tokens to access OAuth 2.0-protected resources

**Digest**

See RFC 7616. Firefox 93 and later support the SHA-256 algorithm. Previous versions only support MD5 hashing (not recommended).

**HOBA**

See RFC 7486, Section 3, **H**TTP **O**rigin-**B**ound **A**uthentication, digital-signature-based

**Mutual**

See RFC 8120

**Negotiate** / **NTLM**

See RFC4599

**VAPID**

See RFC 8292

**SCRAM**

See RFC 7804

**AWS4-HMAC-SHA256**

See AWS docs. This scheme is used for AWS3 server authentication.

Schemes can differ in security strength and in their availability in client or server software.

 The "Basic" authentication scheme offers very poor security, but is widely supported and easy to set up.
 It is introduced in more detail below.

Basic authentication scheme
---------------------------

The "Basic" HTTP authentication scheme is defined in RFC 7617, which transmits credentials as user ID/password pairs, encoded using base64.

### Security of basic authentication

As the user ID and password are passed over the network as clear text (it is base64 encoded, but base64 is a reversible encoding), the basic authentication scheme **is not secure**. HTTPS/TLS should be used with basic authentication. Without these additional security enhancements, basic authentication should not be used to protect sensitive or valuable information.

### Restricting access with Apache and basic authentication

To password-protect a directory on an Apache server, you will need a `.htaccess` and a `.htpasswd` file.

The `.htaccess` file typically looks like this:

```apacheconf
AuthType Basic
AuthName "Access to the staging site"
AuthUserFile /path/to/.htpasswd
Require valid-user
```

The `.htaccess` file references a `.htpasswd` file in which each line consists of a username and a password separated by a colon (`:`). You cannot see the actual passwords as they are hashed (using MD5-based hashing, in this case). Note that you can name your `.htpasswd` file differently if you like, but keep in mind this file shouldn't be accessible to anyone. (Apache is usually configured to prevent access to `.ht*` files).

```apacheconf
aladdin:$apr1$ZjTqBB3f$IF9gdYAGlMrs2fuINjHsz.
user2:$apr1$O04r.y2H$/vEkesPhVInBByJUkXitA/
```

### Restricting access with Nginx and basic authentication

 For Nginx, you will need to specify a location that you are going to protect and the `auth_basic` directive that provides the name to the password-protected area.
 The `auth_basic_user_file` directive then points to a `.htpasswd` file containing the encrypted user credentials, just like in the Apache example above.

```apacheconf
location /status {
    auth_basic           "Access to the staging site";
    auth_basic_user_file /etc/apache2/.htpasswd;
}
```

### Access using credentials in the URL

Many clients also let you avoid the login prompt by using an encoded URL containing the username and the password like this:
```

https://username:password@www.example.com/
```

**The use of these URLs is deprecated**.
 In Chrome, the `username:password@` part in URLs is removed from subresource URLs for security reasons. In Firefox, it is checked if the site actually requires authentication and if not, Firefox will warn the user with a prompt "You are about to log in to the site `www.example.com` with the username `username`, but the website does not require authentication. This may be an attempt to trick you." In case the site does require authentication, Firefox will still ask for user confirmation "You are about to log in to the site `www.example.com` with the username `username`." before sending the credentials to the site. Note that Firefox sends the request without credentials in both cases before showing the prompt in order to determine whether the site requires authentication.

See also
--------

* `WWW-Authenticate`
* `Authorization`
* `Proxy-Authorization`
* `Proxy-Authenticate`
* `401`, `403`, `407`


HTTP response status codes - HTTP

HTTP response status codes
==========================

 HTTP response status codes indicate whether a specific HTTP request has been successfully completed.
 Responses are grouped in five classes:

1. Informational responses (`100` – `199`)
2. Successful responses (`200` – `299`)
3. Redirection messages (`300` – `399`)
4. Client error responses (`400` – `499`)
5. Server error responses (`500` – `599`)

The status codes listed below are defined by RFC 9110.

**Note:** If you receive a response that is not in this list, it is a non-standard response, possibly custom to the server's software.

Information responses
---------------------

`100 Continue`

This interim response indicates that the client should continue the request or ignore the response if the request is already finished.

`101 Switching Protocols`

This code is sent in response to an `Upgrade` request header from the client and indicates the protocol the server is switching to.

`102 Processing` (WebDAV)

This code indicates that the server has received and is processing the request, but no response is available yet.

`103 Early Hints`

This status code is primarily intended to be used with the `Link` header, letting the user agent start preloading resources while the server prepares a response or preconnect to an origin from which the page will need resources.

Successful responses
--------------------

`200 OK`

The request succeeded. The result meaning of "success" depends on the HTTP method:

* `GET`: The resource has been fetched and transmitted in the message body.
* `HEAD`: The representation headers are included in the response without any message body.
* `PUT` or `POST`: The resource describing the result of the action is transmitted in the message body.
* `TRACE`: The message body contains the request message as received by the server.

`201 Created`

The request succeeded, and a new resource was created as a result. This is typically the response sent after `POST` requests, or some `PUT` requests.

`202 Accepted`

 The request has been received but not yet acted upon.
 It is noncommittal, since there is no way in HTTP to later send an asynchronous response indicating the outcome of the request.
 It is intended for cases where another process or server handles the request, or for batch processing.

`203 Non-Authoritative Information`

 This response code means the returned metadata is not exactly the same as is available from the origin server, but is collected from a local or a third-party copy.
 This is mostly used for mirrors or backups of another resource.
 Except for that specific case, the `200 OK` response is preferred to this status.

`204 No Content`

 There is no content to send for this request, but the headers may be useful.
 The user agent may update its cached headers for this resource with the new ones.

`205 Reset Content`

Tells the user agent to reset the document which sent this request.

`206 Partial Content`

This response code is used when the `Range` header is sent from the client to request only part of a resource.

`207 Multi-Status` (WebDAV)

Conveys information about multiple resources, for situations where multiple status codes might be appropriate.

`208 Already Reported` (WebDAV)

Used inside a `<dav:propstat>` response element to avoid repeatedly enumerating the internal members of multiple bindings to the same collection.

`226 IM Used` (HTTP Delta encoding)

The server has fulfilled a `GET` request for the resource, and the response is a representation of the result of one or more instance-manipulations applied to the current instance.

Redirection messages
--------------------

`300 Multiple Choices`

The request has more than one possible response. The user agent or user should choose one of them. (There is no standardized way of choosing one of the responses, but HTML links to the possibilities are recommended so the user can pick.)

`301 Moved Permanently`

The URL of the requested resource has been changed permanently. The new URL is given in the response.

`302 Found`

 This response code means that the URI of requested resource has been changed *temporarily*.
 Further changes in the URI might be made in the future. Therefore, this same URI should be used by the client in future requests.

`303 See Other`

The server sent this response to direct the client to get the requested resource at another URI with a GET request.

`304 Not Modified`

 This is used for caching purposes.
 It tells the client that the response has not been modified, so the client can continue to use the same cached version of the response.

`305 Use Proxy`
Deprecated

 Defined in a previous version of the HTTP specification to indicate that a requested response must be accessed by a proxy.
 It has been deprecated due to security concerns regarding in-band configuration of a proxy.

`306 unused`

This response code is no longer used; it is just reserved. It was used in a previous version of the HTTP/1.1 specification.

`307 Temporary Redirect`

 The server sends this response to direct the client to get the requested resource at another URI with the same method that was used in the prior request.
 This has the same semantics as the `302 Found` HTTP response code, with the exception that the user agent *must not* change the HTTP method used: if a `POST` was used in the first request, a `POST` must be used in the second request.

`308 Permanent Redirect`

 This means that the resource is now permanently located at another URI, specified by the `Location:` HTTP Response header.
 This has the same semantics as the `301 Moved Permanently` HTTP response code, with the exception that the user agent *must not* change the HTTP method used: if a `POST` was used in the first request, a `POST` must be used in the second request.

Client error responses
----------------------

`400 Bad Request`

The server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).

`401 Unauthorized`

 Although the HTTP standard specifies "unauthorized", semantically this response means "unauthenticated".
 That is, the client must authenticate itself to get the requested response.

`402 Payment Required`
Experimental

 This response code is reserved for future use.
 The initial aim for creating this code was using it for digital payment systems, however this status code is used very rarely and no standard convention exists.

`403 Forbidden`

 The client does not have access rights to the content; that is, it is unauthorized, so the server is refusing to give the requested resource.
 Unlike `401 Unauthorized`, the client's identity is known to the server.

`404 Not Found`

 The server cannot find the requested resource.
 In the browser, this means the URL is not recognized.
 In an API, this can also mean that the endpoint is valid but the resource itself does not exist.
 Servers may also send this response instead of `403 Forbidden` to hide the existence of a resource from an unauthorized client.
 This response code is probably the most well known due to its frequent occurrence on the web.

`405 Method Not Allowed`

 The request method is known by the server but is not supported by the target resource.
 For example, an API may not allow calling `DELETE` to remove a resource.

`406 Not Acceptable`

This response is sent when the web server, after performing server-driven content negotiation, doesn't find any content that conforms to the criteria given by the user agent.

`407 Proxy Authentication Required`

This is similar to `401 Unauthorized` but authentication is needed to be done by a proxy.

`408 Request Timeout`

 This response is sent on an idle connection by some servers, even without any previous request by the client.
 It means that the server would like to shut down this unused connection.
 This response is used much more since some browsers, like Chrome, Firefox 27+, or IE9, use HTTP pre-connection mechanisms to speed up surfing.
 Also note that some servers merely shut down the connection without sending this message.

`409 Conflict`

This response is sent when a request conflicts with the current state of the server.

`410 Gone`

 This response is sent when the requested content has been permanently deleted from server, with no forwarding address.
 Clients are expected to remove their caches and links to the resource.
 The HTTP specification intends this status code to be used for "limited-time, promotional services".
 APIs should not feel compelled to indicate resources that have been deleted with this status code.

`411 Length Required`

Server rejected the request because the `Content-Length` header field is not defined and the server requires it.

`412 Precondition Failed`

The client has indicated preconditions in its headers which the server does not meet.

`413 Payload Too Large`

 Request entity is larger than limits defined by server.
 The server might close the connection or return an `Retry-After` header field.

`414 URI Too Long`

The URI requested by the client is longer than the server is willing to interpret.

`415 Unsupported Media Type`

The media format of the requested data is not supported by the server, so the server is rejecting the request.

`416 Range Not Satisfiable`

 The range specified by the `Range` header field in the request cannot be fulfilled.
 It's possible that the range is outside the size of the target URI's data.

`417 Expectation Failed`

This response code means the expectation indicated by the `Expect` request header field cannot be met by the server.

`418 I'm a teapot`

The server refuses the attempt to brew coffee with a teapot.

`421 Misdirected Request`

 The request was directed at a server that is not able to produce a response.
 This can be sent by a server that is not configured to produce responses for the combination of scheme and authority that are included in the request URI.

`422 Unprocessable Content` (WebDAV)

The request was well-formed but was unable to be followed due to semantic errors.

`423 Locked` (WebDAV)

The resource that is being accessed is locked.

`424 Failed Dependency` (WebDAV)

The request failed due to failure of a previous request.

`425 Too Early`
Experimental

Indicates that the server is unwilling to risk processing a request that might be replayed.

`426 Upgrade Required`

 The server refuses to perform the request using the current protocol but might be willing to do so after the client upgrades to a different protocol.
 The server sends an `Upgrade` header in a 426 response to indicate the required protocol(s).

`428 Precondition Required`

 The origin server requires the request to be conditional.
 This response is intended to prevent the 'lost update' problem, where a client `GET`s a resource's state, modifies it and `PUT`s it back to the server, when meanwhile a third party has modified the state on the server, leading to a conflict.

`429 Too Many Requests`

The user has sent too many requests in a given amount of time ("rate limiting").

`431 Request Header Fields Too Large`

 The server is unwilling to process the request because its header fields are too large.
 The request may be resubmitted after reducing the size of the request header fields.

`451 Unavailable For Legal Reasons`

The user agent requested a resource that cannot legally be provided, such as a web page censored by a government.

Server error responses
----------------------

`500 Internal Server Error`

The server has encountered a situation it does not know how to handle.

`501 Not Implemented`

The request method is not supported by the server and cannot be handled. The only methods that servers are required to support (and therefore that must not return this code) are `GET` and `HEAD`.

`502 Bad Gateway`

This error response means that the server, while working as a gateway to get a response needed to handle the request, got an invalid response.

`503 Service Unavailable`

 The server is not ready to handle the request.
 Common causes are a server that is down for maintenance or that is overloaded.
 Note that together with this response, a user-friendly page explaining the problem should be sent.
 This response should be used for temporary conditions and the `Retry-After` HTTP header should, if possible, contain the estimated time before the recovery of the service.
 The webmaster must also take care about the caching-related headers that are sent along with this response, as these temporary condition responses should usually not be cached.

`504 Gateway Timeout`

This error response is given when the server is acting as a gateway and cannot get a response in time.

`505 HTTP Version Not Supported`

The HTTP version used in the request is not supported by the server.

`506 Variant Also Negotiates`

The server has an internal configuration error: the chosen variant resource is configured to engage in transparent content negotiation itself, and is therefore not a proper end point in the negotiation process.

`507 Insufficient Storage` (WebDAV)

The method could not be performed on the resource because the server is unable to store the representation needed to successfully complete the request.

`508 Loop Detected` (WebDAV)

The server detected an infinite loop while processing the request.

`510 Not Extended`

Further extensions to the request are required for the server to fulfill it.

`511 Network Authentication Required`

Indicates that the client needs to authenticate to gain network access.

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* List of HTTP status codes on Wikipedia
* IANA official registry of HTTP status codes