recursal/MDN huggingface dataset:
If-Modified-Since
=================

A requisição do cabeçalho HTTP **`If-Modified-Since`** torna a requisição condicional: o servidor enviará de volta o recurso solicitado, com um status `200`, apenas se foi modificado pela ultima vez após a data fornecida. Se a requisição não foi modificada, a resposta será um `304` sem qualquer corpo; o cabeçalho `Last-Modified` irá conter a data da ultima modificação. Ao contrário `If-Unmodified-Since`, `If-Modified-Since` pode ser apenas utilizado com um `GET` ou `HEAD`.

Quando utilizado em combinação com `If-None-Match`, é ignorado, a menos que não suporte `If-None-Match`.

O uso mais comum é para atualizar uma entidade em cache que não tem um `ETag` associado.

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

Sintaxe
-------
```

If-Modified-Since: <nome-dia>, <dia> <mês> <ano> <hora>:<minuto>:<segundo> GMT
```

Diretivas
---------

<nome-dia>

Um entre "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", or "Sun" (sensível ao caso).

<dia>

2 digitos, número do dia. Por exemplo "04" ou "23".

<mês>

Um entre "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" (sensível ao caso).

<ano>

4 digitos, número do ano,. Por exemplo. "1990" ou "2016".

<hora>

2 digitos, número da hora. Por exemplo. "09" ou "23".

<minuto>

2 digiitos, número do minuto. Por exemplo. "04" ou "59".

<segundos>

2 digitos, número dos segundos, Por exemplo. "04" ou "59".

`GMT`

Horário de Greenwich (Greenwich Mean Time). Datas HTTP sempre são expressas em GMT, nunca em tempo local.

Exemplos
--------
```

If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT
```

Especificações
--------------

| Especificação | Título |
| --- | --- |
| RFC 7232, sessão 3.3: If-Modified-Since | Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests |

Compatibilidade com navegadores
-------------------------------

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

Veja também
-----------

* `ETag`
* `If-Unmodified-since`
* `If-Match`
* `If-None-Match`
* `304` `Not Modified`
Access-Control-Allow-Methods
============================

O cabeçalho de resposta **`Access-Control-Allow-Methods`** especifica o método ou métodos permitidos quando acessando o recurso em resposta a uma preflight request.

|  |  |
| --- | --- |
| Tipo de cabeçalho | Response header (en-US) |
| Forbidden header name | não |

Sintaxe
-------
```

Access-Control-Allow-Methods: <método>, <método>, ...
Access-Control-Allow-Methods: *
```

Diretivas
---------

<método>

Lista separada por vírgula com os métodos de requisição HTTP.

`*` (coringa)

O valor "`*`" só conta como valor coringa para requisições sem credenciais (requisições sem cookies HTTP ou informação de autenticação HTTP). Em requisições com credenciais, isso é tratado como o nome de método literal "`*`" sem qualquer semântica especial.

Exemplos
--------
```

Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Methods: *
```

Especificações
--------------

| Specification |
| --- |
| Fetch Standard # http-access-control-allow-methods |

Compatibilidade com navegadores
-------------------------------

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

Veja também
-----------

* `Access-Control-Allow-Origin`
* `Access-Control-Expose-Headers`
* `Access-Control-Allow-Headers`
* `Access-Control-Request-Method`
Expires
=======

O cabeçalho **`Expires`** contém a data/hora após a qual a resposta é considerada velha.

Datas inválidas, como o valor 0, representam uma data no passado e significam que o recurso já expirou.

Se existe um cabeçalho `Cache-Control` com a diretiva "max-age" ou "s-maxage" na resposta, o cabeçalho `Expires` é ignorado.

|  |  |
| --- | --- |
| Tipo de Header | Response header (en-US) |
| Forbidden header name | não |
| CORS-safelisted response-header (en-US) | sim |

Sintaxe
-------
```

Expires: <http-date>
```

Diretivas
---------

<http-date>

Ums data/hora HTTP-date.

Exemplos
--------
```

Expires: Wed, 21 Oct 2015 07:28:00 GMT
```

Especificações
--------------

| Especificação | Título |
| --- | --- |
| RFC 7234, sessão 5.3: Expires | Hypertext Transfer Protocol (HTTP/1.1): Caching |

Compatibilidade com navegadores
-------------------------------

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

Veja também
-----------

* `Cache-Control`
* `Age`
Accept-Patch
============

O cabeçalho de resposta HTTP **`Accept-Patch`** indica qual tipo de mídia o servidor está apto a entender.

**`Accept-Patch`** na resposta de qualquer método significa que o PATCH é permitido no recurso identificado pela Request-URI. Dois casos comuns que levam a isso:

O servidor recebendo uma requisição PATCH com um tipo de mídia não suportado pode responder com `415` `Unsupported Media Type` e um cabeçalho Accept-Patch referenciando um ou mais tipos de mídia suportados.

**Nota:** **Notas:**- Um registro da IANA mantém uma lista oficial completa das codificações de conteúdo.

* Duas outras codificações de conteúdo, `bzip` e `bzip2`, são algumas vezes utilizadas, entretanto não são o padrão. Elas implementam o algoritmo usado por estes dois programas UNIX. Note que o primeiro foi descontinuado por problemas de patente.


|  |  |
| --- | --- |
| Tipo de cabeçalho | Response header (en-US) |
| Forbidden header name | sim |

Sintaxe
-------
```

Accept-Patch: application/example, text/example
Accept-Patch: text/example;charset=utf-8
Accept-Patch: application/merge-patch+json
```

Diretivas
---------

Nenhuma.

Exemplos
--------
```

Accept-Patch: application/example, text/example

Accept-Patch: text/example;charset=utf-8

Accept-Patch: application/merge-patch+json
```

Especificações
--------------

| Specification | Título |
| --- | --- |
| RFC 5789, sessão 3.1: Accept-Patch | HTTP PATCH |

Compatibilidade com navegadores
-------------------------------

{{Compat}}Veja também
-----------

* Método HTTP `PATCH`
* Semântica e contexto HTTP RFC 7231, sessão 4.3.4: PUT
Proxy-Authorization
===================

O cabeçalho de requisição HTTP **`Proxy-Authorization`** contém as credenciais para autenticar o agente de usuário em um servidor proxy, usualmente depois do servidor responder com um código de status `407` `Proxy Authentication Required` e cabeçalho `Proxy-Authenticate`.

|  |  |
| --- | --- |
| Tipo de cabeçalho | Request header |
| Forbidden header name | não |

Sintaxe
-------
```

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

Diretivas
---------

<type>

Tipo de autentação. Um tipo comum é "Basic". Veja também o registro IANA de esquemas de autenticação.

<credentials>

As credenciais são construídas assim:

* O nome de usuário e senha combinados com dois pontos (`aladdin:opensesame`).
* O resultado é uma cadeia de caracteres codificado em base64 (en-US) (`YWxhZGRpbjpvcGVuc2VzYW1l`).

**Nota:** Codificação Base64 não significa encriptação ou hashing! Esse método é igualmente seguro se mandar as credenciais em texto limpo (base64 é uma codificação reversível). Prefira o uso de HTTPS em conjunto com Autenticação Básica.

Exemplos
--------
```

Proxy-Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
```

Especificações
--------------

| Especificação | Título |
| --- | --- |
| RFC 7235, sessão 4.4: Proxy-Authorization | HTTP/1.1: Authentication |
| RFC 7617 | The 'Basic' HTTP Authentication Scheme |

Veja também
-----------

* Autenticação HTTP
* `Proxy-Authenticate`
* `WWW-Authenticate`
* `Authorization`
* `401`, `403`, `407`
Content-Encoding
================

The **`Content-Encoding`** entity header is used to compress the media-type. When present, its value indicates which encodings were applied to the entity-body. It lets the client know how to decode in order to obtain the media-type referenced by the `Content-Type` header.

The recommendation is to compress data as much as possible and therefore to use this field, but some types of resources, such as jpeg images, are already compressed. Sometimes, using additional compression doesn't reduce payload size and can even make the payload longer.

|  |  |
| --- | --- |
| Tipo de cabeçalho | Entity header |
| Forbidden header name | não |

Sintaxe
-------
```

Content-Encoding: gzip
Content-Encoding: compress
Content-Encoding: deflate
Content-Encoding: identity
Content-Encoding: br

// Múltiplo, em ordem nos quais serão aplicados
Content-Encoding: gzip, identity
Content-Encoding: deflate, gzip
```

Diretivas
---------

`gzip`

A format using the Lempel-Ziv coding (LZ77), with a 32-bit CRC. This is the original format of the UNIX *gzip* program. The HTTP/1.1 standard also recommends that the servers supporting this content-encoding should recognize `x-gzip` as an alias, for compatibility purposes.

`compress`

A format using the Lempel-Ziv-Welch (LZW) algorithm. The value name was taken from the UNIX *compress* program, which implemented this algorithm. Like the compress program, which has disappeared from most UNIX distributions, this content-encoding is not used by many browsers today, partly because of a patent issue (it expired in 2003).

`deflate`

Using the zlib structure (defined in RFC 1950) with the *deflate* compression algorithm (defined in RFC 1951).

`identity`

Indicates the identity function (i.e., no compression or modification). This token, except if explicitly specified, is always deemed acceptable.

`br`

A format using the Brotli algorithm.

Exemplos
--------

### Comprimindo com gzip

On the client side, you can advertise a list of compression schemes that will be sent along in an HTTP request. The `Accept-Encoding` header is used for negotiating content encoding.
```

Accept-Encoding: gzip, deflate
```


The server responds with the scheme used, indicated by the `Content-Encoding` response header.
```

Content-Encoding: gzip
```


Note that the server is not obligated to use any compression method. Compression highly depends on server settings and used server modules.

Especificações
--------------

| Especificação | Título |
| --- | --- |
| RFC 7932: Brotli Compressed Data Format | Brotli Compressed Data Format |
| RFC 7231, sessão 3.1.2.2: Content-Encoding | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |
| RFC 2616, sessão 14.11: Content-Encoding | Content-Encoding |

Compatibilidade com navegadores
-------------------------------

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

Veja também
-----------

* `Accept-Encoding`
* `Transfer-Encoding`
Accept-Language
===============

O cabeçalho HTTP **`Accept-Language`** anuncia quais linguas o cliente é capaz de entender, e qual é a preferência do variante do Locale. (Por Linguas, queremos dizer linguas como Inglês e portugues) Usando content negotiation, o servidor seleciona uma das propostas, usa ela e informa o cliente da sua escolha com o `Content-Language` cabeçalho de responsta. Navegadores configuram valores adequados para este cabeçalhos de acordo com a língua configurada pelo usuario.

Este cabeçalho é uma dica a ser usada pelo servidor quando ele não possui outra forma de determinar a lingua do cliente, como uma URL específica, que é controlada por uma decisão explicita do usuário. É recomendado que o servidor nunca sobreescreva uma decisão explícita. O conteúdo de `Accept-Language` está comumente fora do controle do usuário (em uma viagem a outro país por exemplo); O usuário pode querer acessar a página em outra língua diferente da decidida pelo navegador.

Se o servicor não encontrar uma língua correspondente, ele pode, teóricamente responder com o código de erro`406` (Not Acceptable) . Mas, para uma melhor experiência de usuário, isso raramente é feito. Mais comumente, quando isso ocorre, o cabeçalho é ignorado.

|  |  |
| --- | --- |
| Tipo de Cabeçalho | Request header |
| Forbidden header name | no |
| CORS-safelisted request-header (en-US) | yes |

Syntax
------
```

Accept-Language: <language>
Accept-Language: *

// Multiple types, weighted with the quality value (en-US) syntax:
Accept-Language: fr-CH, fr;q=0.9, en;q=0.8, de;q=0.7, *;q=0.5
```

Diretivas
---------

`<language>`

A tag language (a qual pode ser chamada de "identificador de Locale") consiste de uma tag de 2 a 3 letras representando a lingua, opcionalmente pode ser seguida de um `'-'` separa outras informações extras. A mais comum informação extra é a região do país (como`'pt-BR'` ou `'pt-PT'`) ou o tipo do alfabeto a ser usado (como`'sr-Latn'`). Outras variantes como o tipo de ortografia (`'de-DE-1996'`) normalmente não são utilizadas no contexto deste cabeçalho.

`*`

Qualquer lingua; `'*'` é utilizado como curinga.

`;q=` (q-factor weighting)

Any value placed in an order of preference expressed using a relative quality value (en-US) called *weight*.

Examples
--------
```

Accept-Language: de

Accept-Language: de-CH

Accept-Language: en-US,en;q=0.5
```

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

| Specification | Title |
| --- | --- |
| RFC 7231, sessão 5.3.5: Accept-Language | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Context |
| BCP 47 | Tags for the Identification of Language |

Compatibilidade com navegadores
-------------------------------

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

See also
--------

* HTTP content negotiation
* Header with the result of the content negotiation: `Content-Language`
* Other similar headers: `TE`, `Accept-Encoding`, `Accept-Charset`, `Accept`
Vary
====

O cabeçalho de resposta HTTP **`Vary`** determina como corresponder futuros cabeçalhos de requisição para decidir se uma resposta cacheada pode ser usada ao invés de solicitar uma nova do servidor de origem. Ele é usado pelo servidor para indicar quais cabeçalhos ele utilizou quando selecionando a representação do recurso em um algoritmo de negociação de conteúdo.

O cabeçalho `Vary` deve ser colocado em uma resposta `304` `Not Modified` exatamente como seria colocado em uma resposta `200` `OK` equivalente.

|  |  |
| --- | --- |
| Tipo de cabeçalho | Response header (en-US) |
| Forbidden header name | não |

Sintaxe
-------
```

Vary: *
Vary: <header-name>, <header-name>, ...
```

Diretivas
---------

\*

Cada requisição para a URL é supostamente tratada como uma requisição única e incacheavél. Um jeito melhor de indicar isso é usar `Cache-Control`: `no-store`, que é mais limpo para se ler e também sinaliza que o objeto não deve ser guardado nunca.

<header-name>

Uma lista separada por vírgula de nomes de cabeçalhos para levar em conta quando for decidir se uma resposta cacheada pode ser usada.

Exemplos
--------

### Servimento dinâmico

Quando utilizando o cabeçalho `Vary: User-Agent`, servidores de cacheamento devem considerar o agente de usuário quando estiverem decidindo se irão servir a página do cache. Por exemplo, se você está servindo conteúdo diferente para usuários móveis, ele pode ajudar você a evitar que um cache possa erroneamente servir uma versão desktop do seu site, para os usuários móveis. Ele pode ajudar o Google e outros motores de busca a descobrir a versão móvel da página, e talvez possa dizer a eles que não existe intenção de Cloaking.
```

Vary: User-Agent
```

Especificações
--------------

| Especificação | Título |
| --- | --- |
| RFC 7231, sessão 7.1.4: Vary | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |

Compatibilidade com navegadores
-------------------------------

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

Notas de compatibilidade
------------------------

* Vary com cuidado – Problemas do cabeçalho Vary em IE6-9
Veja também
-----------

* Entendendo o cabeçalho Vary (Understanding The Vary Header) - Smashing Magazine
* Melhores práticas quando utilizando o cabeçalho Vary (Best Practices for Using the Vary Header) – fastly.com
* Negociação de conteúdo
If-Range
========

O cabeçalho de requisição HTTP **`If-Range`** faz uma requisição de intervalo condicional: se a condição é realizada, a requisição de intervalo será enviada e o servidor mandará de volta como resposta um `206` `Partial Content` com o corpo apropriado. Se a condição não é realizada, a recurso inteiro é enviado de volta, com um código de status `200` `OK`.

Este cabeçalho pode ser usado ou com um validador `Last-Modified`, ou com um `ETag`, mas não com ambos.

O caso de uso mais comum é continuar um *download*, para garantir que o recurso guardado não tenha sido modificado desde o último fragmento que foi recebido.

|  |  |
| --- | --- |
| Tipo de cabeçalho | Request header |
| Forbidden header name | não |

Sintaxe
-------
```

If-Range: <nome-dia>, <dia> <mês> <ano> <hora>:<minuto>:<segundo> GMT
If-Range: <etag>
```

Diretivas
---------

<etag>

*Tags* de entidade que representam unicamente os recursos requisitados. Eles são uma cadeia de caracteres ASCII colocados entre aspas duplas (como `"675af34563dc-tr34"`). Elas podem ser prefixadas por `W/` para indicar que o *algoritmo de comparação fraco* deve ser utilizado.

<nome-dia>

Um entre "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", or "Sun" (sensível ao caso).

<dia>

2 digitos, número do dia. Por exemplo "04" ou "23".

<mês>

Um entre "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" (sensível ao caso).

<ano>

4 digitos, número do ano,. Por exemplo. "1990" ou "2016".

<hora>

2 digitos, número da hora. Por exemplo. "09" ou "23".

<minuto>

2 digiitos, número do minuto. Por exemplo. "04" ou "59".

<segundo>

2 digitos, número dos segundo, Por exemplo. "04" ou "59".

`GMT`

Horário de Greenwich (Greenwich Mean Time). Datas HTTP sempre são expressas em GMT, nunca em tempo local.

Exemplos
--------
```

If-Range: Wed, 21 Oct 2015 07:28:00 GMT
```

Especificações
--------------

| Especificação | Título |
| --- | --- |
| RFC 7233, sessão 3.2: If-Range | Hypertext Transfer Protocol (HTTP/1.1): Range Requests |

Compatibilidade com navegadores
-------------------------------

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

Veja também
-----------

* `ETag`
* `Last-Modified`
* `If-Modified-Since`
* `If-Unmodified-Since`
* `If-Match`
* `If-None-Match`
* `206` `Partial Content`
* Requisições Condicionais HTTP (en-US)
Warning
=======

**Nota:** O cabeçalho `Warning` será depreciado em breve; veja Warning (https://github.com/httpwg/http-core/issues/139) e Warning: header & stale-while-revalidate (https://github.com/whatwg/fetch/issues/913) para mais detalhes.

O cabeçalho geral HTTP **`Warning`** contém informação sobre possíveis problemas com o status da mensagem. Mais de um cabeçalho `Warning` pode aparecer na resposta.

O cabeçalho `Warning` geralmente pode ser aplicado para qualquer mensagem, entretanto alguns códigos de aviso são específicos para caches e podem somente ser aplicados para mensagens de resposta.

|  |  |
| --- | --- |
| Tipo de cabeçalhos | General header |
| Forbidden header name | não |

Sintaxe
-------
```

Warning: <warn-code> <warn-agent> <warn-text> [<warn-date>]
```

Diretivas
---------

<warn-code>

Um número de aviso de três dígitos. O primeiro dígito indica se é necessário o `Warning` ser deletado de uma resposta guardada depois da validação.

* Códigos de aviso `1xx` descrevem o frescor ou status de validação da resposta e será deletado por um cache depois da deleção.
* Códigos de aviso `2xx` descrevem algum aspecto da representação que não é retificada por uma validação e não será deletado por uma cache depois da validação a não que a resposta completa seja enviada.

<warn-agent>

O nome ou pseudônimo do servidor ou software adicionando o cabeçalho `Warning` (pode ser "-" quando o agente não é conhecido).

<warn-text>

Texto consultivo descrevendo o erro.

<warn-date>

Opcional. Se mais de um cabeçalho `Warning` é enviado, inclui a data que corresponde com o cabeçalho `Date`.

Códigos de aviso (Warning)
--------------------------

O registro de Códigos de Aviso HTTP em iana.org define o espaço de nomes para códigos de aviso.

| Código | Texto | Descrição |
| --- | --- | --- |
| 110 | Resposta está velha | A resposta provida pela cache está velha (o tempo de expiração já passou). |
| 111 | Revalidação falhou | Uma tentaiva de validar a resposta falhou, por causa da impossibilidade de alcançar o servidor. |
| 112 | Operação Desconectou | O cache desconectou do resto da rede. |
| 113 | Expiração Heurística | Enviado se a cache escolhe heuristicamente um tempo de vida fresco maior que 24 horas e a idade da resposta é maior que 24 horas. |
| 199 | Aviso diverso | Arbitrário, aviso não específico. |
| 214 | Transformação aplicada | Adicionado por um proxy se ele aplica qualquer transformação na representação, como mudar a codificação de conteúdo, tipo de media ou semelhante. |
| 299 | Aviso diverso persistente | O mesmo que 199, mas indicando um aviso persistente. |

Exemplos
--------
```

Warning: 110 anderson/1.3.37 "Response is stale"

Date: Wed, 21 Oct 2015 07:28:00 GMT
Warning: 112 - "cache down" "Wed, 21 Oct 2015 07:28:00 GMT"
```

Especificações
--------------

| Especificação | Título |
| --- | --- |
| RFC 7234, sessão 5.5: Warning | Hypertext Transfer Protocol (HTTP/1.1): Caching |

Compatibilidade com navegadores
-------------------------------

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

Veja também
-----------

* `Date`
* Código de resposta de status HTTP
Accept-Ranges
=============

O cabeçalho de resposta HTTP **`Accept-Ranges`** é um marcador usado pelo servidor para indicar que ele suporta requisições parciais. O valor deste campo indica a unidade utilizada para definir o tamanho.

Na presença do cabeçalho `Accept-Ranges`, o navegador pode tentar retomar um *download* interrompido, ao invés de começar de novo do início.

|  |  |
| --- | --- |
| Tipo de cabeçalho | Response header (en-US) |
| Forbidden header name | não |

Sintaxe
-------
```

Accept-Ranges: bytes
Accept-Ranges: none
```

Diretivas
---------

`none`

Nenhuma unidade de tamanho é suportada, isso faz com que o cabeçalho seja equivalente a sua própria ausência, sendo então raramente usado, apesar de que alguns navegadores, como o IE9, é usado para habilitar ou desabilitar os botões de pausa no gerenciador de downloads.

`bytes`

A unidade de tamanho são bytes.

Exemplos
--------
```

Accept-Ranges: bytes
```

Especificações
--------------

| Especificação | Título |
| --- | --- |
| RFC 7233, sessão 2.3: Accept-Ranges | Hypertext Transfer Protocol (HTTP/1.1): Range Requests |

Compatibilidade com navegadores
-------------------------------

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

Veja também
-----------

* `If-Range`
* `Range`
Cross-Origin-Resource-Policy
============================

**Nota:** Devido a um bug no Chrome, configurar Cross-Origin-Resource-Policy pode quebrar a renderização de PDF, impedindo visitantes de conseguir ler além da primeira página de alguns PDFs. Utilize com cuidado este cabeçalho em um ambiente de produção.

O cabeçalho de resposta HTTP **`Cross-Origin-Resource-Policy`** indica um desejo que o navegador bloqueie requisições que não sejam entre origens e/ou entre sites para um dado recurso.

|  |  |
| --- | --- |
| Tipo de cabeçalho | Response header (en-US) |
| Forbidden header name | não |

Sintaxe
-------
```

Cross-Origin-Resource-Policy: same-site | same-origin | cross-origin
```

Exemplos
--------

O cabeçalho de resposta abaixo pode causar a agentes de usuário compatíveis a desabilitar requisição que não sejam entre origens:
```

Cross-Origin-Resource-Policy: same-origin
```


Para mais exemplos, veja https://resourcepolicy.fyi/.

Especificações
--------------

| Specification |
| --- |
| Fetch Standard # cross-origin-resource-policy-header |

Compatibilidade com navegadores
-------------------------------

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

Veja também
-----------

* Explicação da Cross-Origin Resource Policy (CORP) (en-US)
* Considere usar Cross-Origin Resource Policy