recursal/MDN huggingface dataset:
507 Insufficient Storage
========================

The HyperText Transfer Protocol (HTTP) **`507 Insufficient Storage`** response status code may be given in the context of the Web Distributed Authoring and Versioning (WebDAV) protocol (see RFC 4918).

It indicates that a method could not be performed because the server cannot store the representation needed to successfully complete the request.

Status
------


```http
507 Insufficient Storage
```

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

| Specification |
| --- |
| RFC 4918 # section-11.5 |
428 Precondition Required
=========================

 The HTTP **`428 Precondition Required`** response status code
 indicates that the server requires the request to be conditional.

 Typically, this means that a required precondition header, such
 as `If-Match`, **is missing**.

 When a precondition header is **not matching** the server side state, the
 response should be `412` `Precondition Failed`.

Status
------


```http
428 Precondition Required
```

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

| Specification |
| --- |
| RFC 6585 # section-3 |

See also
--------

* HTTP conditional requests
* `If-Match`
* `412`
200 OK
======

The HTTP **`200 OK`** success status response code indicates that the request has succeeded. A 200 response is cacheable by default.

The meaning of a success depends on the HTTP request method:

* `GET`: The resource has been fetched and is transmitted in the message body.
* `HEAD`: The representation headers are included in the response without any message body
* `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.

The successful result of a `PUT` or a `DELETE` is often not a `200 OK` but a `204` `No Content` (or a `201` `Created` when the resource is uploaded for the first time).

Status
------


```http
200 OK
```

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

| Specification |
| --- |
| HTTP Semantics # status.200 |

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

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

See also
--------

* HTTP request methods
PUT
===

The **HTTP `PUT` request method** creates a new resource or replaces a representation of the target resource with the request payload.

The difference between `PUT` and `POST` is that `PUT` is idempotent: calling it once or several times successively has the same effect (that is no *side* effect), whereas successive identical `POST` requests may have additional effects, akin to placing an order several times.

|  |  |
| --- | --- |
| Request has body | Yes |
| Successful response has body | May |
| Safe | No |
| Idempotent | Yes |
| Cacheable | No |
| Allowed in HTML forms | No |

Syntax
------


```http
PUT /new.html HTTP/1.1
```

Example
-------

### Request


```http
PUT /new.html HTTP/1.1
Host: example.com
Content-type: text/html
Content-length: 16

<p>New File</p>
```

### Responses

If the target resource does not have a current representation and the `PUT` request successfully creates one, then the origin server must inform the user agent by sending a `201` (`Created`) response.


```http
HTTP/1.1 201 Created
Content-Location: /new.html
```


If the target resource does have a current representation and that representation is successfully modified in accordance with the state of the enclosed representation, then the origin server must send either a `200` (`OK`) or a `204` (`No Content`) response to indicate successful completion of the request.


```http
HTTP/1.1 204 No Content
Content-Location: /existing.html
```

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

| Specification |
| --- |
| HTTP Semantics # PUT |

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

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

See also
--------

* `201`
* `204`
CONNECT
=======

 The **HTTP `CONNECT` method** starts two-way communications
 with the requested resource. It can be used to open a tunnel.

 For example, the `CONNECT` method can be used to access websites that use
 TLS (HTTPS). The client asks an HTTP Proxy
 server to tunnel the TCP connection to
 the desired destination. The server then proceeds to make the connection on behalf of
 the client. Once the connection has been established by the server, the
 Proxy server continues to proxy the TCP stream to and
 from the client.

`CONNECT` is a hop-by-hop method.

|  |  |
| --- | --- |
| Request has body | No |
| Successful response has body | No |
| Safe | No |
| Idempotent | No |
| Cacheable | No |
| Allowed in HTML forms | No |

Syntax
------


```http
CONNECT www.example.com:443 HTTP/1.1
```

Example
-------

 Some proxy servers might need authority to create a tunnel. See also the
 `Proxy-Authorization` header.


```http
CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80
Proxy-Authorization: basic aGVsbG86d29ybGQ=
```

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

| Specification |
| --- |
| HTTP Semantics # CONNECT |

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

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

See also
--------

* Proxy server
* `Proxy-Authorization`
DELETE
======

 The **HTTP `DELETE` request method** deletes the specified
 resource.


|  |  |
| --- | --- |
| Request has body | May |
| Successful response has body | May |
| Safe | No |
| Idempotent | Yes |
| Cacheable | No |
| Allowed in HTML forms | No |

Syntax
------


```http
DELETE /file.html HTTP/1.1
```

Example
-------

### Request


```http
DELETE /file.html HTTP/1.1
Host: example.com
```

### Responses

 If a `DELETE` method is successfully applied, there are several response
 status codes possible:

* A `202` (`Accepted`) status code if the action will
 likely succeed but has not yet been enacted.
* A `204` (`No Content`) status code if the action has been
 enacted and no further information is to be supplied.
* A `200` (`OK`) status code if the action has been enacted
 and the response message includes a representation describing the status.


```http
HTTP/1.1 200 OK
Date: Wed, 21 Oct 2015 07:28:00 GMT

<html>
  <body>
    <h1>File deleted.</h1>
  </body>
</html>
```

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

| Specification |
| --- |
| HTTP Semantics # DELETE |

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

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

See also
--------

* HTTP status: `200`, `202`, `204`
POST
====

The **HTTP `POST` method** sends data to the server. The type of the body of the request is indicated by the `Content-Type` header.

The difference between `PUT` and `POST` is that `PUT` is idempotent: calling it once or several times successively has the same effect (that is no *side* effect), where successive identical `POST` may have additional effects, like passing an order several times.

A `POST` request is typically sent via an HTML form and results in a change on the server. In this case, the content type is selected by putting the adequate string in the `enctype` attribute of the `<form>` element or the `formenctype` attribute of the `<input>` or `<button>` elements:

* `application/x-www-form-urlencoded`: the keys and values are encoded in key-value tuples separated by `'&'`, with a `'='` between the key and the value. Non-alphanumeric characters in both keys and values are URL encoded: this is the reason why this type is not suitable to use with binary data (use `multipart/form-data` instead)
* `multipart/form-data`: each value is sent as a block of data ("body part"), with a user agent-defined delimiter ("boundary") separating each part. The keys are given in the `Content-Disposition` header of each part.
* `text/plain`

When the `POST` request is sent via a method other than an HTML form, such as a `fetch()` call, the body can take any type. As described in the HTTP 1.1 specification, `POST` is designed to allow a uniform method to cover the following functions:

* Annotation of existing resources
* Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles;
* Adding a new user through a signup modal;
* Providing a block of data, such as the result of submitting a form, to a data-handling process;
* Extending a database through an append operation.

|  |  |
| --- | --- |
| Request has body | Yes |
| Successful response has body | Yes |
| Safe | No |
| Idempotent | No |
| Cacheable | Only if freshness information is included |
| Allowed in HTML forms | Yes |

Syntax
------


```http
POST /test
```

Example
-------

A simple form using the default `application/x-www-form-urlencoded` content type:


```http
POST /test HTTP/1.1
Host: foo.example
Content-Type: application/x-www-form-urlencoded
Content-Length: 27

field1=value1&field2=value2
```


A form using the `multipart/form-data` content type:


```http
POST /test HTTP/1.1
Host: foo.example
Content-Type: multipart/form-data;boundary="boundary"

--boundary
Content-Disposition: form-data; name="field1"

value1
--boundary
Content-Disposition: form-data; name="field2"; filename="example.txt"

value2
--boundary--
```

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

| Specification |
| --- |
| HTTP Semantics # POST |

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

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

See also
--------

* `Content-Type`
* `Content-Disposition`
* `GET`
GET
===

The **HTTP `GET` method** requests a representation of the specified resource. Requests using `GET` should only be used to request data (they shouldn't include data).

**Note:** Sending body/payload in a `GET` request may cause some existing implementations to reject the request — while not prohibited by the specification, the semantics are undefined. It is better to just avoid sending payloads in `GET` requests.


|  |  |
| --- | --- |
| Request has body | No |
| Successful response has body | Yes |
| Safe | Yes |
| Idempotent | Yes |
| Cacheable | Yes |
| Allowed in HTML forms | Yes |

Syntax
------


```http
GET /index.html
```

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

| Specification |
| --- |
| HTTP Semantics # GET |

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

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

See also
--------

* HTTP Headers
* `Range`
* `POST`
HEAD
====

The **HTTP `HEAD` method** requests the headers that would be returned if the `HEAD` request's URL was instead requested with the HTTP `GET` method. For example, if a URL might produce a large download, a `HEAD` request could read its `Content-Length` header to check the filesize without actually downloading the file.

**Warning:** A response to a `HEAD` method *should not* have a body. If it has one anyway, that body **must be** ignored: any representation headers that might describe the erroneous body are instead assumed to describe the response which a similar `GET` request would have received.

If the response to a `HEAD` request shows that a cached URL response is now outdated, the cached copy is invalidated even if no `GET` request was made.

|  |  |
| --- | --- |
| Request has body | No |
| Successful response has body | No |
| Safe | Yes |
| Idempotent | Yes |
| Cacheable | Yes |
| Allowed in HTML forms | No |

Syntax
------


```http
HEAD /index.html
```

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

| Specification |
| --- |
| HTTP Semantics # HEAD |

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

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

See also
--------

* `GET`
TRACE
=====

The **HTTP `TRACE` method** performs a message loop-back test along the path to the target resource, providing a useful debugging mechanism.

The final recipient of the request should reflect the message received, excluding any fields that might include sensitive data, back to the client as the message body of a `200` (`OK`) response with a `Content-Type` of `message/http`. The final recipient is either the origin server or the first server to receive a `Max-Forwards` value of 0 in the request.

Note that the client must not send content in the request, or generate fields that might include sensitive data, such as stored user credentials or cookies.

|  |  |
| --- | --- |
| Request has body | No |
| Successful response has body | Yes |
| Safe | Yes |
| Idempotent | Yes |
| Cacheable | No |
| Allowed in HTML forms | No |

Syntax
------


```http
TRACE /index.html
```

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

| Specification |
| --- |
| HTTP Semantics # TRACE |

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

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

See also
--------

* HTTP methods
PATCH
=====

The **HTTP `PATCH` request method** applies partial modifications to a resource.

`PATCH` is somewhat analogous to the "update" concept found in CRUD (in general, HTTP is different than CRUD, and the two should not be confused).

A `PATCH` request is considered a set of instructions on how to modify a resource. Contrast this with `PUT`; which is a complete representation of a resource.

A `PATCH` is not necessarily idempotent, although it can be. Contrast this with `PUT`; which is always idempotent. The word "idempotent" means that any number of repeated, identical requests will leave the resource in the same state. For example if an auto-incrementing counter field is an integral part of the resource, then a `PUT` will naturally overwrite it (since it overwrites everything), but not necessarily so for `PATCH`.

`PATCH` (like `POST`) *may* have side-effects on other resources.

To find out whether a server supports `PATCH`, a server can advertise its support by adding it to the list in the `Allow` or `Access-Control-Allow-Methods` (for CORS) response headers.

Another (implicit) indication that `PATCH` is allowed, is the presence of the `Accept-Patch` header, which specifies the patch document formats accepted by the server.

|  |  |
| --- | --- |
| Request has body | Yes |
| Successful response has body | May |
| Safe | No |
| Idempotent | No |
| Cacheable | Only if freshness information is included |
| Allowed in HTML forms | No |

Syntax
------


```http
PATCH /file.txt HTTP/1.1
```

Example
-------

### Request


```http
PATCH /file.txt HTTP/1.1
Host: www.example.com
Content-Type: application/example
If-Match: "e0023aa4e"
Content-Length: 100

[description of changes]
```

### Response

A successful response is indicated by any 2xx status code.

In the example below a `204` response code is used, because the response does not carry a payload body. A `200` response could have contained a payload body.


```http
HTTP/1.1 204 No Content
Content-Location: /file.txt
ETag: "e0023aa4f"
```

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

| Specification |
| --- |
| RFC 5789  |

See also
--------

* `204`
* `Allow`, `Access-Control-Allow-Methods`
* `Accept-Patch` – specifies the patch document formats accepted by the server.
CSP errors and warnings (Content Security Policy)
=================================================

When you see any of the following messages logged in the browser devtools console, it indicates that a problem related to CSP has occurred.

* The page's settings blocked the loading of a resource: %1$S
* The page's settings blocked the loading of a resource at %2$S ("%1$S").
* A violation occurred for a report-only CSP policy ("%1$S"). The behavior was allowed, and a CSP report was sent.
* The page's settings observed the loading of a resource at %2$S ("%1$S"). A CSP report is being sent.
* Tried to send report to invalid URI: "%1$S"
* Couldn't parse report URI: %1$S
* Couldn't process unknown directive '%1$S'
* Ignoring unknown option %1$S
* Ignoring duplicate source %1$S
* Ignoring source '%1$S' (Not supported when delivered via meta element).
* Ignoring "%1$S" within script-src or style-src: nonce-source or hash-source specified
* Ignoring "%1$S" within script-src: 'strict-dynamic' specified
* Ignoring source "%1$S" (Only supported within script-src).
* Keyword 'strict-dynamic' within "%1$S" with no valid nonce or hash might block all scripts from loading
* The report URI (%1$S) should be an HTTP or HTTPS URI.
* This site (%1$S) has a Report-Only policy without a report URI. CSP will not block and cannot report violations of this policy.
* Failed to parse unrecognized source %1$S
* An attempt to execute inline scripts has been blocked
* An attempt to apply inline style sheets has been blocked
* An attempt to call JavaScript from a string (by calling a function like eval) has been blocked
* Upgrading insecure request '%1$S' to use '%2$S'
* Ignoring srcs for directive '%1$S'
* Interpreting %1$S as a hostname, not a keyword. If you intended this to be a keyword, use '%2$S' (wrapped in single quotes).
* Not supporting directive '%1$S'. Directive and values will be ignored.
* Blocking insecure request '%1$S'.(/en-US/docs/Web/HTTP/CSP/Errors/blockAllMixedContent)
* Ignoring '%1$S' since it does not contain any parameters.
* Ignoring sandbox directive when delivered in a report-only policy '%1$S'
* Referrer Directive '%1$S' has been deprecated. Please use the Referrer-Policy header instead.
* Ignoring '%1$S' because of '%2$S' directive.
* Couldn't parse invalid source %1$S
* Couldn't parse invalid host %1$S
* Couldn't parse scheme in %1$S
* Couldn't parse port in %1$S
* Duplicate %1$S directives detected. All but the first instance will be ignored.
* Directive '%1$S' has been deprecated. Please use directive 'worker-src' to control workers, or directive 'frame-src' to control frames respectively.
* Couldn't parse invalid sandbox flag '%1$S'
Content Security Policy: The page's settings blocked the loading of a resource: xyz
===================================================================================

The warning "Content Security Policy: The page's settings blocked the loading of a resource: xyz" occurs when the page's CSP configuration given by `xyz` prevents the resource from being loaded into the document's context.

Message
-------

### Firefox

`Content Security Policy: The pages settings blocked the loading of a resource: xyz`

with:

`xyz`

The name of the CSP directive that blocked the resource. This may be expressed as either just the name of the directive, or as the entire policy directive string.

`uvw`

Text that provides information that may help you resolve the problem, potentially including specific changes you might make to the CSP configuration.

### Chrome

* `Refused to apply inline style because it violates the following Content Security Policy Directive: "xyz". uvw.`
* `Refused to execute inline script because it violates the following Content Security Policy directive: "xyz". uvw.`
* `Refused to run the JavaScript URL because it violates the following Content Security Policy directive: "xyz". uvw.`
* `Refused to execute inline event handler because it violates the following Content Security Policy directive: "xyz". uvw.`

with:

`xyz`

The name of the CSP directive that blocked the resource. This may be expressed as either just the name of the directive, or as the entire policy directive string.

`uvw`

Text that provides information that may help you resolve the problem, potentially including specific changes you might make to the CSP configuration.

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

This warning message means that due to the existence of a particular CSP directive, a resource wasn't loaded.

See also
--------

* CSP errors and warnings
* Content Security Policy
* `Content-Security-Policy`
* `Content-Security-Policy-Report-Only`
Service-Worker-Navigation-Preload
=================================

 The **`Service-Worker-Navigation-Preload`** request header indicates that the request was the result of a `fetch()` operation made during service worker navigation preloading.
 It allows a server to respond with a different resource than for a normal `fetch()`.

If a different response may result from setting this header, the server must set `Vary: Service-Worker-Navigation-Preload` to ensure that the different responses are cached.

For more information see `NavigationPreloadManager.setHeaderValue()` (and `NavigationPreloadManager`).

|  |  |
| --- | --- |
| Header type | Request header |
| Forbidden header name | no |

Syntax
------


```http
Service-Worker-Navigation-Preload: <value>
```

Directives
----------

`<value>`

 An arbitrary value that indicates what data should be sent in the response to the preload request.
 This defaults to `true`.
 It maybe set to any other string value in the service worker, using `NavigationPreloadManager.setHeaderValue()`.


Examples
--------

The header below is sent by default.


```http
Service-Worker-Navigation-Preload: true
```


 The service worker can set a different header value using `NavigationPreloadManager.setHeaderValue()`.
 For example, in order to request that a fragment of the requested resource be returned in JSON format, the value could be set with the string `json_fragment1`.


```http
Service-Worker-Navigation-Preload: json\_fragment1
```

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

| Specification |
| --- |
| Service Workers # handle-fetch |

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

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.
Access-Control-Request-Headers
==============================

The **`Access-Control-Request-Headers`** request header is used by browsers when issuing a preflight request to let the server know which HTTP headers the client might send when the actual request is made (such as with `fetch()` or `XMLHttpRequest.setRequestHeader()`). The complementary server-side header of `Access-Control-Allow-Headers` will answer this browser-side header.

|  |  |
| --- | --- |
| Header type | Request header |
| Forbidden header name | yes |

Syntax
------


```http
Access-Control-Request-Headers: <header-name>, <header-name>, …
```

Directives
----------

<header-name>

A comma-delimited list of HTTP headers that are included in the request.

Examples
--------


```http
Access-Control-Request-Headers: X-PINGOTHER, Content-Type
```

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

| Specification |
| --- |
| Fetch Standard # http-access-control-request-headers |

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

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

See also
--------

* `Access-Control-Request-Method`
Supports-Loading-Mode
=====================

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

The **`Supports-Loading-Mode`** response header is set by a navigation target to opt-in to using various higher-risk loading modes.

|  |  |
| --- | --- |
| Header type | Response header |
| Forbidden header name | no |
| CORS-safelisted response header | no |

Syntax
------


```http
Supports-Loading-Mode: credentialed-prerender
```

Directives
----------

The `Supports-Loading-Mode` header is a list of one or more tokens, which can include the following values:

`credentialed-prerender` 
Experimental

Indicates that a destination origin opts in to loading documents via cross-origin, same-site prerendering.

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

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

See also
--------

* Speculation Rules API
* Speculative loading
* Prerender pages in Chrome for instant page navigations on developer.chrome.com (2023)