X-XSS-Protection - HTTP

X-XSS-Protection
================

O cabeçalho de resposta HTTP **`X-XSS-Protection`** é uma funcionalidade do Internet Explorer, Chrome e Safari que impede páginas de carregarem quando eles detectam ataques de scripting entre sites (XSS (en-US)) refletidos. Apesar destas proteções serem majoritariamente desnecessárias em navegadores modernos em sites utilizando uma forte `Content-Security-Policy` que desabilita o uso de JavaScript *inline* (`'unsafe-inline'`), eles ainda podem oferecer proteções para usuários de navegadores mais antigos que ainda não suportam CSP (en-US).

**Nota:** - Chrome removeu o XSS Auditor deles

* Firefox não tem, e não irá implementar `X-XSS-Protection`
* Edge aposentou o filtro XSS delesIsso significa que se você não precisa dar suporte para navegadores legado, é recomendado que você use `Content-Security-Policy` sem permitir scripts `unsafe-inline` ao invés disso.

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

Sintaxe
-------
```

X-XSS-Protection: 0
X-XSS-Protection: 1
X-XSS-Protection: 1; mode=block
X-XSS-Protection: 1; report=<reporting-uri>
```

0

Desabilita filtragem XSS.

1

Habilita filtragem XSS (geralmente padrão em navegadores). Se um ataque de scripting entre sites é detectado, o navegador irá higienizar a página (remover as partes inseguras).

1; mode=block

Habilita filtragem XSS. Ao invés de higienizar a página, o navegador irá impedir a renderização da página em que o ataque foi detectado.

1; report=<reporting-URI> (Chromium somente)

Habilita filtragem XSS. Se o ataque de scripting entre sites é detectado, o navegador irá higienizar a página e reportar a violação. Isso utiliza a funcionalidade da diretiva CSP `report-uri` (en-US) para enviar o relatório.

Exemplos
--------

Bloqueia páginas de carregarem quando elas detectam ataques XSS refletidos:

```bash
X-XSS-Protection: 1; mode=block
```

PHP

```php
header("X-XSS-Protection: 1; mode=block");
```

Apache (.htaccess)

```bash
<IfModule mod_headers.c>
  Header set X-XSS-Protection "1; mode=block"
</IfModule>
```

Nginx

```bash
add_header "X-XSS-Protection" "1; mode=block";
```

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

Não faz parte de nenhuma especificação ou rascunho.

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

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

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

* `Content-Security-Policy`
* Controlando o XSS Filter (Controlling the XSS Filter) – Microsoft
* Entendendo o XSS Auditor (Understanding XSS Auditor) – Virtue Security
* O mal-entendido X-XSS-Protection (The misunderstood X-XSS-Protection) – blog.innerht.ml


Via - HTTP

Via
===

O cabeçalho geral **`Via`** é adicionado por proxies, ambos diretos e reversos, e pode aparecer em cabeçalhos de requisição e de cabeçalhos de resposta. Ele é usado para rastrear mensagens direcionadas, evitando laços de requisição, e identificando as capacidades dos protocolos dos remetentes ao longo da cadeia de requisição/resposta.

|  |  |
| --- | --- |
| Tipo de cabeçalho | General header |
| Forbidden header name | sim |

Sintaxe
-------
```

Via: [ <protocol-name> "/" ] <protocol-version> <host> [ ":" <port> ]
or
Via: [ <protocol-name> "/" ] <protocol-version> <pseudonym>
```

Diretivas
---------

<protocol-name>

Opcional. O nome do protocolo usado, como "HTTP".

<protocol-version>

A versão do protocolo usado, como "1.1".

<host> e <port>

URL pública do proxy e sua porta.

<pseudonym>

Nome/pseudônimo de um proxy interno.

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

Via: 1.1 vegur
Via: HTTP/1.1 GWA
Via: 1.0 fred, 1.1 p.example.net
```

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

| Especificação | Título |
| --- | --- |
| RFC 7230, sessão 5.7.1: Via | Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing |

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

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

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

* `X-Forwarded-For`
* Biblioteca proxy Vegur do Heroku


Content-Security-Policy - HTTP

Content-Security-Policy
=======================

O cabeçalho de resposta HTTP **`Content-Security-Policy`** permite aos administradores do site, ter controle sobre os recursos que o agente de usuário é permitido carregar para uma certa página. Com algumas pequenas exceções, políticas majoritariamente envolvem especificar as origens do servidor e pontos de acessos dos *scripts*. Isso ajuda contra ataques de *scripting* entre sites (XSS (en-US)).

Para mais informações, veja o artigo introdutório em Política de Segurança de Conteúdo (*Content Security Policy*)(CSP).

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

Sintaxe
-------
```

Content-Security-Policy: <policy-directive>; <policy-directive>
```

Diretivas
---------

### Fetch directives (en-US)

Diretivas de busca (*Fetch directives*) controlam as localizações dos quais certos tipos de recursos podem ser carregados.

#### Lista de Diretivas de busca de Política de Segurança de Conteúdo (CSP)

`child-src` (en-US)

Define uma origem válida para web workers e contextos aninhados de navegação carregados usando elementos como `<frame>` (en-US) e `<iframe>`.

**Aviso:** Ao invés de **`child-src`**, os autores que querem regular contextos de navegação aninhadas e trabalhores devem usar as diretivas `frame-src` (en-US) e `worker-src` (en-US), respectivamente.

`connect-src` (en-US)

Restringe a URL que pode ser carregada usando interfaces de script.

`default-src` (en-US)

Funciona como recuo para a outra fetch directives (en-US).

`font-src` (en-US)

Especifica origens válidas para as fontes de letras carregadas usando `@font-face`.

`frame-src` (en-US)

Especifica origens válidas para carregamento de contextos de navegação aninhados usando elementos como `<frame>` (en-US) e `<iframe>`.

`img-src` (en-US)

Especifica origens válidas para imagens e ícones.

`manifest-src` (en-US)

Especifica origens válidas dos arquivos de manifesto da aplicação.

`media-src` (en-US)

Especifica origens válidas para carregar dados de media usando os elementos `<audio>` , `<video>` e `<track>`.

`object-src` (en-US)

Especifica origens válidas para os elementos `<object>` (en-US), `<embed>`, e `<applet>`.

**Nota:** Elementos controlados por `object-src` sejam talvez considerados elementos HTML legados e não estão recebendo novas funcionalidades padrão (como os atributos de segurança `sandbox` ou `allow` para `<iframe>`). Sendo assim é **recomendado** restringir o uso desta diretiva (e.g. colocar explicitamente `object-src 'none'` se possível).

`prefetch-src` (en-US)
Experimental

Especifica origens válidas para serem pré-carregadas ou pré-renderizadas.

`script-src` (en-US)

Especifica origens válidas para JavaScript.

`script-src-elem` (en-US)
Experimental

Especifica origens válidas para elementos JavaScript `<script>`.

`script-src-attr` (en-US)
Experimental

Especifica origens válidas para *handlers* de eventos JavaScript *inline*.

`style-src` (en-US)

Especifica origens válidas para arquivos de estilo.

`style-src-elem` (en-US)
Experimental

Especifica origens válidas para elementos de estilo `<style>` e elementos `<link>` com `rel="stylesheet"`.

`style-src-attr` (en-US)
Experimental

Especifica origens válidas para estilos dentro de linha aplicados a elementos DOM individuais.

`worker-src` (en-US)
Experimental

Especifica origens válidas para scripts `Worker`, `SharedWorker` (en-US), ou `ServiceWorker` (en-US).

### Document directives (en-US)

As diretivas de Documento governam as propriedades de um documento ou ambiente worker (trabalhador) para qual a política se aplica.

#### Lista de diretivas de Documento da Política de Segurança de Conteúdo

`base-uri` (en-US)

Restringe as URLs que podem ser usadas em um elemento `<base>` do documento.

`plugin-types` (en-US)

Restringe o conjunto de *plugins* que podem ser embutidos em um documento limitando pelos tipos de conteúdos que podem ser carregados.

`sandbox` (en-US)

Habilita o *sandbox* para um recurso requisitado similar ao atributo `sandbox` de `<iframe>`.

### Navigation directives (en-US)

Diretivas de Navegação governam para qual localização um usuário pode navegar ou submeter um formulário para, por exemplo.

#### Lista de diretivas de Navegação da Política de Segurança de Conteúdo

`form-action` (en-US)

Restringe as URLs que podem ser usadas como alvo para as submissões de um formulário para um dado contexto.

`frame-ancestors` (en-US)

Especifica pais válidos que podem embutir uma página usando `<frame>` (en-US), `<iframe>`, `<object>` (en-US), `<embed>`, ou `<applet>`.

`navigate-to` (en-US)
Experimental

Restringe as URLs para qual um documento pode iniciar navegação quaisquer sejam os motivos, incluindo `<form>` (en-US) (se `form-action` (en-US) não for especificado), `<a>`, `window.location`, `window.open` (en-US), etc.

### Reporting directives (en-US)

Diretivas de Relatório controlam o processo de reportar as violações CSP. Veja também o cabeçalho `Content-Security-Policy-Report-Only`.

#### Lista de Diretivas de Relatório da Política de Segurança de Conteúdo

`report-uri` (en-US)
Deprecated

Instrui ao agente de usuário para reportar tentativas de violaçnao de Política de Segurança de Conteúdo. Esses relatórios de violação consistem de documentos JSON enviados por requisição HTTP `POST` para uma URI especificada.

**Aviso:** Apesar da diretiva `report-to` (en-US) tem a inteção de trocar a diretiva depreciada **`report-uri`**, `report-to` (en-US) não é suportado na maioria dos navegadores ainda. Então para compatibilidade com os navegadores atuais enquanto adiciona a compatibilidade com `report-to` (en-US), você pode especificar ambos **`report-uri`** e `report-to` (en-US):
```

Content-Security-Policy: ...; report-uri https://endpoint.example.com; report-to groupname
```

Em navegadores que suportam `report-to` (en-US), a diretiva **`report-uri`** será ignorada.

`report-to` (en-US)
Experimental

Dispara um `SecurityPolicyViolationEvent`.

### Outras diretivas

`block-all-mixed-content` (en-US)

Previne carregamento de quaisquer recursos usando HTTP quando a página é carregada usando HTTPS.

`referrer` (en-US)
Deprecated

Non-standard

Era usado para especificar informação no cabeçalho de referência (sic) para links fora da página. Ao invés disso, use o cabeçalho `Referrer-Policy`.

`require-sri-for` (en-US)
Experimental

Obriga o uso de SRI (en-US) para *scripts* ou estilos na página.

`require-trusted-types-for` (en-US)
Experimental

Impõe Trusted Types (Tipos confiáveis) em coletores de eventos (vide: Sink (Computing)) para evitar injeção de DOM XSS.

`trusted-types` (en-US)
Experimental

Usado para especificar uma lista branca de políticas Trusted Types (Tipos confiáveis) (Tipos confiáveis permitem aplicações travarem injeções DOM XSS em coletores de eventos (*sinks*) para aceitarem somente valores tipados não falsificáveis no lugar de *strings*.

`upgrade-insecure-requests` (en-US)

Instrui o usuário de agente a tratar todas as URLs inseguras de um site (aquelas servidas através do HTTP) a serem trocadas por URLs seguras (aqueles servidas através de HTTPS). Essa diretiva tem como foco sites com grande número de URLs inseguras e legadas que precisam ser reescritas.

CSP em workers(trabalhadores)
-----------------------------

Workers (trabalhadores) em geral não são governados pela política de segurança de conteúdo do documento (ou trabalhador pai) que os criou. Para especificar uma política de segurança de conteúdo para um trabalhador, coloque um cabeçalho de resposta `Content-Security-Policy` para a requisição que pediu o *script* do trabalhador em si.

A exceção à isso é se o *script* original do trabalhador é um identificador único global (por exemplo, se a URL tem um esquema de dados ou *blob*). Neste caso, o trabalhador herda a política de segurança de conteúdo do documento ou trabalhador que o criou.

Múltiplas políticas de segurança de conteúdo
--------------------------------------------

CSP permite múltiplas políticas sendo especificadas para um recurso, através dos cabeçalhos `Content-Security-Policy`, `Content-Security-Policy-Report-Only` e do elemento `<meta>`.

Você pode usar o cabeçalho `Content-Security-Policy` mais de uma vez como no exemplo abaixo. Preste atenção a diretiva `connect-src` (en-US) aqui. Mesmo que a segunda política permitiria a conexão, a primeira política contém `connect-src 'none'`. Adicionando políticas adicionais *podem somente restringir* as capacidades do recurso protegido, o que significa que não haverá conexão permitida e, como política mais restrita, `connect-src 'none'` é imposto.
```

Content-Security-Policy: default-src 'self' http://example.com;
                         connect-src 'none';
Content-Security-Policy: connect-src http://example.com/;
                         script-src http://example.com/
```

Exemplos
--------

Exemplo: Desabilitar *inline/eval* inseguros, permitindo somente carregamento de conteúdos (imagens, fontes de letras, scripts, etc.) através do HTTPS:
```

// cabeçalho
Content-Security-Policy: default-src https:

// meta tag
<meta http-equiv="Content-Security-Policy" content="default-src https:">
```

Exemplo: Site pré-existente que usa muito código dentro de linha para corrigir mas quer assegurar que os recursos são carregador somente através de HTTPS e desabilita plugins:
```

Content-Security-Policy: default-src https: 'unsafe-eval' 'unsafe-inline'; object-src 'none'
```

Exemplo: Não implemente a política acima ainda, ao invés disso, somente reporte as violações que podem ter ocorrido:
```

Content-Security-Policy-Report-Only: default-src https:; report-uri /csp-violation-report-endpoint/
```

Veja as Mozilla Web Security Guidelines para mais exemplos.

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

| Specification |
| --- |
| Content Security Policy Level 3 # csp-header |

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

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

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

* `Content-Security-Policy-Report-Only`
* Aprenda sobre: Content Security Policy
* Segurança de Conteúdo em Extensões Web (en-US)
* Adotando uma política estrita
* Avaliador CSP - Avalie sua Política de Segurança de Conteúdo


Content-Disposition - HTTP

Content-Disposition
===================

Em uma resposta HTTP normal, o cabeçalho de resposta **`Content-Disposition`** indica se o conteúdo é esperado a ser exibido *inline* no navegador, isso significa, como uma página Web ou parte de uma, ou como um anexo, que é baixado e salvo localmente.

Em um corpo `multipart/form-data`, o cabeçalho geral HTTP **`Content-Disposition`** é um cabeçalho que pode ser utilizado em uma subparte de um corpo multipartes para dar informações sobre o campo a que ele se aplica. A subparte é delimitada pelo limite definido no cabeçalho `Content-Type`. Usado no corpo em si, `Content-Disposition` não tem efeito.

O cabeçalho `Content-Disposition` é definido em um grande contexto de mensagens MIME para e-mail, mas somente um subconjunto dos possíveis parâmetros são aplicados à formulários HTTP e requisições `POST` requests. Somente o valor `form-data`, assim como a diretiva opcional `name` e `filename`, podem ser usadas no contexto HTTP.

|  |  |
| --- | --- |
| Tipo de cabeçalho | Response header (en-US) (para o corpo principal)General header
 (para a subparte de um corpo multipartes)
  |
| Forbidden header name | não |

Sintaxe
-------

### Como cabeçalho de resposta para o corpo principal

O primeiro parâmetro no contexto HTTP ou é `inline` (valor padrão, indicando que ele pode ser mostrado dentro de uma página Web, ou como uma página Web) ou `attachment` (indicando que ele deve ser baixado; a maioria dos navegadores apresenta uma caixa de diálogo "Salvar como", pré-preenchido com o valor do parâmetro `filename` se presente).
```

Content-Disposition: inline
Content-Disposition: attachment
Content-Disposition: attachment; filename="filename.jpg"
```

### Como cabeçalho para um corpo multipartes

O primeiro parâmetro no contexto HTTP é sempre o `form-data`. Parâmetros adicionais são *case-insensitive* e possuem argumentos que usam a sintaxe de cadeia de caracteres delimitadas por aspas depois do sinal `'='`. Múltiplos parâmetros são separados por um ponto e vírgula (`';'`).
```

Content-Disposition: form-data
Content-Disposition: form-data; name="fieldName"
Content-Disposition: form-data; name="fieldName"; filename="filename.jpg"
```

### Diretivas

`name`

O nome é seguido por uma cadeia de caracteres contendo o nome do campo HTML no formulário que o conteúdo dessa subparte se refere. Quando lidando com múltiplos arquivos no mesmo campo (por exemplo, o atributo `multiple` de um elemento `{HTMLElement("input","<input type=\"file\">")}}`), podem haver diversas subpartes com o mesmo nome.

Um `name` com o valor de `'_charset_'` indica que a parte não é um campo HTML, mas uma codificação para usar em partes sem explicitar a informação de codificação.

`filename`

É seguido por uma cadeia de caracteres contendo o nome original do arquivo transmitido. O nome do arquivo é sempre opcional e não deve ser usado cegamente pela aplicação: informação de caminho deve ser removida, e conversão para as regras do sistema de arquivo do servidor devem ser feitas. Este parâmetro provém a maior parte da informação indicativa. Quando usado em combinação com `Content-Disposition: attachment`, ele é usado como nome de arquivo padrão para uma eventual caixa de diálogo "Salvar como" apresentado ao usuário.

`filename*`

Os parâmetros "filename" e "filename\*" se diferenciam somente no fato de que "filename\*" usa a codificação definida na RFC 5987. Quando ambos "filename" e "filename\*" estão presentes em um único campo de valor do cabeçalho, "filename\*" é preferido sobre "filename" quando ambos são entendidos.

Exemplos
--------

Uma resposta ativando a caixa de diálogo "Salvar como":
```

200 OK
Content-Type: text/html; charset=utf-8
Content-Disposition: attachment; filename="cool.html"
Content-Length: 21

<HTML>Me salve!</HTML>
```

O simples arquivo HTML será salvo como um download regular ao invés de ser mostrado no navegador. A maioria dos navegadores irá propôr salvar o arquivo como nome de `cool.html` (por padrão).

Um exemplo de um formulário de HTML postado usando o formato `multipart/form-data` que faz o uso do cabeçalho `Content-Disposition`:
```

POST /test.html HTTP/1.1
Host: example.org
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--
```

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

| Especificação | Título |
| --- | --- |
| RFC 7578 | Returning Values from Forms: multipart/form-data |
| RFC 6266 | Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP) |
| RFC 2183 | Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field |

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

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

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

* Firefox 5 lida com o cabeçalho de resposta HTTP `Content-Disposition` mais efetivamente se ambos parâmetros `filename` e `filename*` são providos; ele olha através de todos os nomes providenciados, usando o parâmetro `filename*` se um estiver disponível, mesmo se o parâmetro `filename` estiver incluído primeiro. Anteriormente, o primeiro parâmetro que combinasse seria utilizado, Previously, the first matching parameter would be used, desse modo prevenindo um nome mais apropriado de ser utilizado. Veja Erro do Firefox 588781.
Veja também
-----------

* Formulários HTML
* O cabeçalho `Content-Type` definindo o limite do corpo multipartes.
* A interface `FormData` usada para manipular dados de formulários para uso na API `XMLHttpRequest`.


Tk - HTTP

Tk
==

O cabeçalho de resposta **`Tk`** indica o status de rastreamento que foi aplicado à requisição correspondente.

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

Sintaxe
-------
```

Tk: !  (em construção)
Tk: ?  (dinâmico)
Tk: G  (portão ou múltiplas partes)
Tk: N  (não está rastreando)
Tk: T  (rastreando)
Tk: C  (rastreando com consentimento)
Tk: P  (potencial consentimento)
Tk: D  (desconsiderando DNT)
Tk: U  (atualizado)
```

### Diretivas

!

Em construção. O servidor de origem está atualmente testando sua comunicação de status de rastreamento.

?

Dinâmico. O servidor de origem precisa de mais informação para determinar o status de rastreamento.

G

Portão ou múltiplas partes. O servidor está agindo como um portão para uma troca envolvendo várias múltiplas partes.

N

Não está rastreando.

T

Rastreando.

C

Rastreamento com consentimento. O servidor de origem acredita que ele recebeu consentimento a priori para rastrear o usuário, agente de usuário ou dispositivo.

P

Potencial consentimento. O servidor origem não conhece, em tempo real, se ele recebeu consentimento a priori para rastrear o usuário, o agente de usuário ou dispositivo, mas promete não usar ou compartilhar qualquer dado `DNT:1` até que o consentimento seja determinado, e promete futuramente deletar ou permanentemente sumir com a identidade em até 48 horas para qualquer dado `DNT:1` recebido para qual o consentimento não tenha sido recebido.

D

Desconsiderando DNT. O servidor de origem está incapacitado ou relutante em respeitar uma preferência de rastreamento recebida do agente de usuário requisitante.

U

Atualizado. A requisição resultou em uma potencial mudança no status de rastreamento aplicado ao usuário, agente de usuário ou dispositivo.

Exemplos
--------

O cabeçalho `Tk` para um recurso que diz não querer ser rastreado se parece com isso:
```

Tk: N
```

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

#### No specification found

No specification data found for `http.headers.Tk`.
Check for problems with this page or contribute a missing `spec_url` to mdn/browser-compat-data. Also make sure the specification is included in w3c/browser-specs.

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

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

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

* Cabeçalho `DNT`
* `Navigator.doNotTrack` (en-US)


Access-Control-Max-Age - HTTP

Access-Control-Max-Age
======================

O cabeçalho de resposta **`Access-Control-Max-Age`** indica por quanto tempo os resultados de uma preflight request (que é a informação contida nos cabeçalhos `Access-Control-Allow-Methods` e `Access-Control-Allow-Headers`) pode ser cacheada (mantida).

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

Sintaxe
-------
```

Access-Control-Max-Age: <delta-segundos>
```

Diretivas
---------

<delta-segundos>

 Número máximo de segundos que os resultados podem ser cacheados.
 Firefox limita isso em 24 horas (86400 segundos).
 Chromium (anterior à v76) limita isso à 10 minutos (600 segundos).
 Chromium (começando na v76) limita isso à 2 horas (7200 segundos).
 Chromium também especifica o valor padrão de 5 segundos.
 O valor de **-1** irá desabilitar o cacheamento, requerendo uma requisição de checagem pré-vôo OPTIONS para todas as chamadas.

Exemplos
--------

Resultados cacheados para uma requisição pré-vôo por 10 minutos:
```

Access-Control-Max-Age: 600
```

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

| Specification |
| --- |
| Fetch Standard # http-access-control-max-age |

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

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

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

* `Access-Control-Allow-Headers`
* `Access-Control-Allow-Methods`


Upgrade-Insecure-Requests - HTTP

Upgrade-Insecure-Requests
=========================

O cabeçalho HTTP **`Upgrade-Insecure-Requests`** envia um sinal ao servidor expressando a preferência do cliente por uma resposta criptografada e autenticada, e podendo manipular com êxito a diretiva `upgrade-insecure-requests` (en-US) CSP (en-US).

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

Syntaxe
-------
```

Upgrade-Insecure-Requests: 1
```

Exemplos
--------

Um cliente solicita ao servidor que ele faça o suporte aos mecanismos de upgrade de `upgrade-insecure-requests` (en-US):
```

GET / HTTP/1.1
Host: example.com
Upgrade-Insecure-Requests: 1
```

O servidor agora pode redirecionar para uma versão segura do site. Um cabeçalho `Vary` pode ser usado para que o site não seja veiculado por caches à clientes que não oferecem suporte ao mecanismo de upgrade.
```

Local: https://example.com/
Vary: Upgrade-Insecure-Requests
```

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

| Specification |
| --- |
| Upgrade Insecure Requests # preference |

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

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

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

* `Content-Security-Policy`
* CSP `upgrade-insecure-requests` (en-US) directive


Save-Data - HTTP

Save-Data
=========

O cabeçalho **`Save-Data`** é um booleano no qual, em requisições, indica a preferência do cliente para reduzir uso de dados. Isso pode ser por algumas razões como custo de transferência alto, baixa velocidade de conexão, etc.

Um valor de `On` indica uma opção explícita do usuário em querer reduzir a quantidade de dados usados no cliente, e quando comunicade para origens permite elas entregarem conteúdo alternativo para reduzir a quantidade de dados baixados como recursos de imagem e vídeo menores, marcação e estilo diferente, desabilitar *polling* e atualizações automáticas, e assim por diante.

**Nota:** Desabilitar HTTP/2 Server Push (RFC 7540, sessão 8.2: Server Push) pode ser desejável para reduzir o *download* de dados.

Sintaxe
-------
```

Save-Data: <sd-token>
```

Diretivas
---------

`<sd-token>`

Um valor numérico indicando se o cliente quer optar ou não em entrar em modo de utilização de dados reduzido. `on` significa sim, enquanto `off` (o padrão) indica não.

Exemplos
--------

O cabeçalho `Vary` assegura que o conteúdo é cacheado apropriadamante (por exemplos assegurando que o usuário não é servido com uma imagem de baixa qualidade do cache quando o cabeçalho `Save-Data` não está mais presente [*e.g.* depois de ter trocado de rede celular para Wi-Fi]).

### Com `Save-Data: on`

Requisição:
```

GET /image.jpg HTTP/1.0
Host: example.com
Save-Data: on
```

Resposta:
```

HTTP/1.0 200 OK
Content-Length: 102832
Vary: Accept-Encoding, Save-Data
Cache-Control: public, max-age=31536000
Content-Type: image/jpeg

[...]
```

### Sem `Save-Data`

Requisição:
```

GET /image.jpg HTTP/1.0
Host: example.com
```

Resposta:
```

HTTP/1.0 200 OK
Content-Length: 481770
Vary: Accept-Encoding, Save-Data
Cache-Control: public, max-age=31536000
Content-Type: image/jpeg

[...]
```

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

| Especificação | Título |
| --- | --- |
| draft-grigorik-http-client-hints-03, section 7: Save-Data | HTTP Client Hints |

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

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

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

* Ajude seus usuários a "salvar-dados" (Help Your Users `Save-Data`) - CSS Tricks
* Entregando aplicações leves e rápidas com Save-Data (Delivering Fast and Light Applications with Save-Data) - Google Developers
* Cabeçalho para indicar que o conteúdo servidor varia por `Save-Data`: `Vary`
* Funcionalidade CSS @media `prefers-reduced-data` (en-US)
Experimental


Access-Control-Expose-Headers - HTTP

Access-Control-Expose-Headers
=============================

O cabeçalho de resposta **`Access-Control-Expose-Headers`** indica quais cabeçalhos podem ser expostos como parte da resposta listando os seus nomes.

Por padrão, somente os 6 CORS-safelisted response headers (en-US) são expostos:

* `Cache-Control`
* `Content-Language`
* `Content-Type`
* `Expires`
* `Last-Modified`
* `Pragma`

Se você quiser que clientes tenham acesso a outros cabeçalhos, você deve listá-los usando o cabeçalho `Access-Control-Expose-Headers`.

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

Sintaxe
-------
```

Access-Control-Expose-Headers: <nome-do-cabeçalho>, <nome-do-cabeçalho>, ...
Access-Control-Expose-Headers: *
```

Diretivas
---------

<nome-do-cabeçalho>

Uma lista dos cabeçalhos expostos contendo zero ou mais nomes de cabeçalhos além dos CORS-safelisted request headers (en-US) que o recurso pode usar e expor.

`*` (coringa)

 O valor "`*`" conta somente como um valor coringa para requisições sem credenciais (requisições sem cookies HTTP ou informação de autenticação HTTP). Em requisições com credenciais, ele é tratado como o nome de cabeçalho literal "`*`" sem qualquer semântica.
 Note que o cabeçalho `Authorization` não pode ter valor coringa e sempre precisa ser listado explicitamente.

Exemplos
--------

Para expor um cabeçalho de requisição não-CORS-seguro, você pode especificar:
```

Access-Control-Expose-Headers: Content-Length
```

Para expor um cabeçalho customizado adicionalmente, como `X-Kuma-Revision`, você pode adicionar múltiplos cabeçalhos separados por vírgula:
```

Access-Control-Expose-Headers: Content-Length, X-Kuma-Revision
```

Em requisições sem credênciais, você também pode usar um valor coringa:
```

Access-Control-Expose-Headers: *
```

Entretanto, isso não irá colocar um valor coringa para o cabeçalho `Authorization`, então caso você precise que ele seja exposto, você precisa listá-lo explicitamente:
```

Access-Control-Expose-Headers: *, Authorization
```

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

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

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

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

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

* `Access-Control-Allow-Headers`
* `Access-Control-Allow-Origin`


GET - HTTP

GET
===

O **método HTTP GET** solicita uma representação do recurso especificado. Solicitações usando GET só devem recuperar dados.

|  |  |
| --- | --- |
| Requisição tem corpo | Não |
| Resposta bem-sucedida tem corpo | Sim |
| Seguro | Sim |
| Idempotente | Sim |
| Cacheável | Sim |
| Permitido em formulários HTML | SIm |

Sintaxe
-------
```

GET /index.html
```

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

| Especificação | Título |
| --- | --- |
| RFC 7231, sessão 4.3.1: GET | 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.

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

* `Range`


CONNECT - HTTP

CONNECT
=======

O \*\*médoto HTTP `CONNECT` \*\*começa a comunicação bidirecional com o recurso solicitado. Ele pode ser usado para abrir um túnel.

Por exemplo, o método `CONNECT` pode ser utilizado para acessar websites que usam SSL (en-US) (HTTPS). O cliente solicita a um servidor proxy HTTP que tunelize a conexão TCP para o destino desejado. O servidor então procede para fazer a conexão em nome do cliente. Uma vez que a conexão foi estabelecida pelo servidor, o servidor Proxy continua a proxy do fluxo TCP para e do cliente.

`CONNECT` é um método hop-by-hop.

|  |  |
| --- | --- |
| Requisição tem corpo | Sim |
| Resposta bem sucedida tem corpo | Sim |
| Seguro | Não |
| Idempotente | Não |
| Cacheável | Não |
| Permitido em formulários HTML | Não |

Sintaxe
-------
```

CONNECT www.exemplo.com:443 HTTP/1.1
```

Exemplo
-------

Alguns servidores de proxy podem precisar de autoridade para criar um túnel. Veja mais no header `Proxy-Authorization`

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

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

| Especificação | Título |
| --- | --- |
| RFC 7231, sessão 4.3.6: CONNECT | Hypertext Transfer Protocol (HTTP/1.1): Semântica e conteúdo |

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

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

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

* Servidor proxy
* `Proxy-Authorization`


DELETE - HTTP

DELETE
======

O **método de requisição HTTP DELETE** remove o recurso especificado.

|  |  |
| --- | --- |
| Requisição tem corpo | Talvez |
| A resposta bem sucedida tem corpo | Talvez |
| Seguro | Não |
| Idempotente | Sim |
| Cacheável | Não |
|
 Aceito nos
 formulários HTML | Não |

Sintaxe
-------
```

DELETE /arquivo.html HTTP/1.1
```

Exemplo
-------

### Requisição
```

DELETE /arquivo.html HTTP/1.1
```

### Respostas

Se um método `DELETE` for aplicado com sucesso, há muitos códigos de status de resposta possíveis:

* Um código de status `202` (`Accepted`) se a ação provavelmente teve sucesso, porém ainda não foi realizada.
* Um código de status `204` (`No Content`) se a ação foi realizada e nenhuma outra informação deve ser fornecida.
* Um código de status `200` (`OK`) se a ação foi realizada e a mensagem de resposta inclui uma representação descrevendo o status.
```

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

<html>
  <body>
    <h1>Arquivo removido.</h1>
  </body>
</html>
```

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

| Especificação | Título |
| --- | --- |
| RFC 7231, sessão 4.3.5: DELETE | Protocolo de Transferência de Hipertexto (HTTP/1.1): Semântica e conteúdo |

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

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

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

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


POST - HTTP

POST
====

O **método HTTP `POST`** envia dados ao servidor. O tipo do corpo da solicitação é indicado pelo cabeçalho `Content-Type`.

A diferença entre `PUT` e `POST` é que `PUT` é idempotente: chamá-lo uma vez ou várias vezes sucessivamente tem o mesmo efeito (ou seja, nenhum efeito colateral), onde sucessivos POST idênticos podem ter efeitos adicionais, assim como passando uma ordem várias vezes.

Uma solicitação `POST` geralmente é enviada por meio de um formulário HTML e resulta em uma alteração no servidor. Nesse caso, o tipo de conteúdo é selecionado colocando a string adequada no atributo `enctype` (en-US) do elemento `<form>` (en-US) ou o atributo `formenctype` dos elementos `<input>` ou `<button>`:

* `application/x-www-form-urlencoded`: as chaves e valores são codificados em tuplas de valor-chave separadas por `'&'`, com um `'='` entre a chave e o valor. Caracteres não alfanuméricos em chaves e valores são percent encoded (en-US): este é o motivo pelo qual esse tipo não é adequado para uso com dados binários (ao invés disso, use `multipart/form-data`)
* `multipart/form-data`
* `text/plain`

Quando a requisição `POST` é enviada através de um método diferente de um formulário HTML - como por meio de um `XMLHttpRequest` - o corpo pode assumir qualquer tipo. Conforme descrito na especificação HTTP 1.1, o `POST` é projetado para permitir que um método uniforme cubra as seguintes funções:

* Anotação de recursos existentes
* Postar uma mensagem em um quadro de avisos, newsgroup, lista de emails ou grupo similar de artigos;
* Adicionando um novo usuário através de um modal de inscrição;
* Fornecendo um bloco de dados, como o resultado do envio de um formulário, para um processo de manipulação de dados;
* Estendendo um banco de dados por meio de uma operação de *append*.

|  |  |
| --- | --- |
| Requisição tem corpo | Sim |
| Resposta bem-sucedida tem corpo | Sim |
| Seguro | Não |
| Idempotente | Não |
| Cacheável | Somente se as informações de atualização estiverem incluídas |
|
 Permitido em
 formulários HTML | Sim |

Sintaxe
-------
```

POST /index.html
```

Exemplo
-------

Um simples formulário utilizando o padrão *content type* `application/x-www-form-urlencoded`:

```http
POST / HTTP/1.1
Host: foo.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 13

say=Hi&to=Mom
```

Um formulário utilizando o *content type* `multipart/form-data`:

```http
POST /test.html HTTP/1.1
Host: example.org
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
```

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

| Especificação | Título |
| --- | --- |
| RFC 7231, sessão 4.3.3: POST | 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.

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

* `Content-Type`
* `Content-Disposition`


PATCH - HTTP

PATCH
=====

O **método de requisição HTTP PATCH** aplica modificações parciais a um recurso.

O método HTTP `PUT` permite apenas substituições completas de um documento. Em contraste ao `PUT`, o método `PATCH` não é idempotente, ou seja, requisições sucessivas idênticas *podem* obter efeitos distintos. Todavia, é possível realizar requisições `PATCH` de modo a serem idempotentes.

`PATCH` (assim como `PUT`) podem ter efeitos colaterais em outros recursos.

Para descobrir se um servidor dá suporte a `PATCH`, um servidor pode divulgar seu suporte adicionando tal suporte à lista no cabeçalho de resposta HTTP `Allow` ou `Access-Control-Allow-Methods` (para CORS).

Outra indicação (implícita) da permissão de PATCH é a presença do cabeçalho `Accept-Patch`, que especifica o formato do documento patch aceito pelo servidor.

|  |  |
| --- | --- |
| Requisição possui corpo | Sim |
| Resposta sucedida possui corpo | Sim |
| Safe | Não |
| Idempotent | Não |
| Cacheable (en-US) | Não |
|
 Permitido em
 formulários HTML | Não |

Sintaxe
-------
```

PATCH /file.txt HTTP/1.1
```

Exemplo
-------

### Requisição

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

[descrição das mudanças]
```

### Resposta

Uma resposta sucedida é indicada pelo *status* de resposta `204`, visto que a resposta não carrega um corpo de mensagem.

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

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

| Especificação | Título |
| --- | --- |
| RFC 5789: PATCH | PATCH Method for HTTP |

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

* `204`
* `Allow`, `Access-Control-Allow-Methods`
* `Accept-Patch` – Especifica o documento patch aceito pelo servidor.


PUT - HTTP

PUT
===

O **método de requisição** **HTTP PUT** cria um novo recurso ou subsititui uma representação do recurso de destino com os novos dados.

A diferença entre `PUT` e `POST` é que `PUT` é idempotente: chamá-lo uma ou várias vezes sucessivamente terá o mesmo efeito (não é um efeito colateral), enquanto usar `POST` repetidamente pode ter efeitos adicionais, como passar uma ordem várias vezes.

|  |  |
| --- | --- |
| A requisição tem corpo | Sim |
| Resposta bem sucedida tem corpo | Não |
| Safe | Não |
| Idempotent | Sim |
| Cacheable (en-US) | Não |
|
 Permitido em
 formulários HTML | Não |

Sintaxe
-------
```

PUT /new.html HTTP/1.1
```

Exemplo
-------

### Solicitação
```

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

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

### Resposta

Se o recurso de destino não tem uma representação atual e a requisição `PUT` foi criada com sucesso, então o servidor original deve informar o agente de usuário enviando uma resposta `201` (`Created`).
```

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

Se o recurso de destino tem uma representação atual e essa representação é modificada com sucesso de acordo com o estado de representação em anexo, então o servidor original deve enviar também uma resposta `200` (`OK`) or a `204` (`No Content`) para indicar a conclusão da requisição.
```

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

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

| Specification | Title |
| --- | --- |
| RFC 7231, sessão 4.3.4: PUT | Hypertext Transfer Protocol (HTTP/1.1): Semântica e conteúdo. |

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

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

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

* `201`
* `204`


HEAD - HTTP

HEAD
====

O **método HTTP `HEAD`** solicita os cabeçalhos retornados de um recurso específico que foi requisitado por um método HTTP `GET`. Tal solicitação pode ser feita antes de baixar um grande recurso para economizar largura de banda, por exemplo.

Uma resposta para um método `HEAD` não deve ter um corpo. Se tiver, deve ser ignorado. Mesmo assim, entity headers (cabeçalhos de entidade) descrevendo o conteúdo do corpo (como `Content-Length`) podem ser incluidos na resposta. Eles não se relacionam com o corpo da resposta `HEAD`, que deve estar vazio, e sim com o corpo de solicitação relacionado, usando o método `GET` que teria retornado como resposta.

Se a resposta de uma solicitação `HEAD` mostrar que um recurso armazenado em cache após uma requisição `GET` está desatualizado, o cache é invalidado, mesmo se nenhuma solicitação `GET` tiver sido feita.

|  |  |
| --- | --- |
| Solicitação tem um corpo | Não |
| A resposta bem sucedida tem um corpo | Não |
| Safe | Sim |
| Idempotent | Sim |
| Cacheable (en-US) | Sim |
|
 Permitido em
 formulário HTML | Não |

Sintaxe
-------
```

HEAD /index.html
```

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

| Especificação | Título |
| --- | --- |
| RFC 7231, sessão 4.3.2: HEAD | Hypertext Transfer Protocol (HTTP/1.1): Semântica e Conteúdo |

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

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

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

* `GET`


OPTIONS - HTTP

OPTIONS
=======

O \*\*método HTTP `OPTIONS` \*\*é utilizado para que um cliente possa descobrir quais as opções de requisição permitidas para um determinado recurso em um servidor. O cliente pode especificar uma URL específica no método `OPTIONS` ou um asterisco(\*) indicando que se refere ao servidor como um todo para sanar suas dúvidas em relação as opções de requisição permitidas.

|  |  |
| --- | --- |
| Request possui corpo | Não |
| Resposta bem sucedida possui corpo | Não |
| Seguro | Sim |
| Idempotente | Sim |
| Cacheável | Não |
| Permitido em formulários HTML | Não |

Sintaxe
-------
```

OPTIONS /index.html HTTP/1.1
OPTIONS * HTTP/1.1
```

Exemplos
--------

### Descobrindo quais tipos de requisição são permitidas

Para descobrir quais tipos de requisição um servidor suporta, é possível utilizar o curl e enviar uma requisição OPTIONS:
```

curl -X OPTIONS http://example.org -i
```

A resposta terá um cabeçalho `Allow` com os métodos permitidos:
```

HTTP/1.1 200 OK
Allow: OPTIONS, GET, HEAD, POST
Cache-Control: max-age=604800
Date: Thu, 13 Oct 2016 11:45:00 GMT
Expires: Thu, 20 Oct 2016 11:45:00 GMT
Server: EOS (lax004/2813)
x-ec-custom-error: 1
Content-Length: 0
```

### Requisições Preflighted no CORS

No CORS (en-US), uma requisição preflight com o método OPTIONS é enviada para que o servidor possa indicar se é possível enviar uma requisição específica com os parâmetros informados. No exemplo abaixo, o cabeçalho `Access-Control-Request-Method` indica para o servidor que quando a requisição específica for enviada, ela será enviada como uma requisição POST. O cabeçalho `Access-Control-Request-Headers` indica para o servidor que quando a requisição específica for enviada, ela será enviada com os cabeçalhos customizados `X-PINGOTHER` e `Content-Type`. A partir desta requisição com o método OPTIONS, o servidor possui a oportunidade de indicar se a requisição específica será aceita da forma como foi indicada pelos parâmetros supracitados (o método POST e os dois cabeçalhos customizados).
```

OPTIONS /resources/post-here/ HTTP/1.1
Host: bar.other
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Origin: http://foo.example
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type
```

Em nosso exemplo, o servidor responde com `Access-Control-Allow-Methods` indicando que os métodos `POST`, `GET`, e `OPTIONS` são permitidos para utilização em relação ao recurso em questão. Este cabeçalho é similar ao cabeçalho de resposta `Allow` , no entanto ele somente é utilizado no contexto do CORS.
```

HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:39 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://foo.example
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400
Vary: Accept-Encoding, Origin
Content-Encoding: gzip
Content-Length: 0
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain
```

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

| Especificação | Título |
| --- | --- |
| RFC 7231, sessão 4.3.7: OPTIONS | 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.

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

* `Allow` header
* CORS (en-US)


TRACE - HTTP

TRACE
=====

O **método** \*\*HTTP `TRACE` \*\*realiza um teste de loopback enviando uma mensagem por todo o caminho até o recurso alvo no qual foi destinado, provendo um mecanismo útil para debug.

O destinatário final deve responder a mensagem recebida, excluindo alguns campos descritos abaixo, de volta para o client com um status code 200 (OK) e um cabeçalho `Content-Type`. O destinatário final pode ser o servidor de origem ou o primeiro servidor a receber a requisição com o cabeçalho `Max-Forwards` (en-US) com valor 0.

|  |  |
| --- | --- |
| Requisição possui body | No |
| Resposta com sucesso possui body | No |
| Seguro | No |
| Idempotent | Yes |
| Cacheavel | No |
| Permitido nos formatos HTML | No |

Sintaxe
-------
```

TRACE /index.html
```

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

| Specification | Title |
| --- | --- |
| RFC 7231, sessão 4.3.8: TRACE | 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.

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

* HTTP methods


Lista de valores padrões de Accept - HTTP

Lista de valores padrões de Accept
==================================

Este artigo documenta os valores padrão para o cabeçalho HTTP `Accept` para entradas e versões específicas do navegador.

Valores padrão
--------------

Estes são os valores enviados quando o contexto não fornece mais informações. Observe que todos os navegadores adicionam o tipo MIME `*/*` para cobrir todos os casos. Isso é normalmente usado para solicitações iniciadas por meio da barra de endereços de um navegador ou por meio de um elemento HTML `<a>`.

| User Agent | Valor | Comentário |
| --- | --- | --- |
| Firefox | `text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8` (desde o Firefox 66) `text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8` (no Firefox 65) `text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8` (antes) | No Firefox 65 e versões anteriores, esse valor pode ser modificado usando o parâmetro `network.http.accept.default`. (fonte) |
| Safari, Chrome | `text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8` | (fonte) |
| Safari 5 | `text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8` | Esta é uma melhoria em comparação com os cabeçalhos `Accept` já que não mais classifica `image/png` acima de `text/html` |
| Internet Explorer 8 | `image/jpeg, application/x-ms-application, image/gif, application/xaml+xml, image/pjpeg, application/x-ms-xbap, application/x-shockwave-flash, application/msword, */*` | Veja IE and the Accept Header (blog de MSDN da IEInternals). |
| Edge | `text/html, application/xhtml+xml, image/jxr, */*` |  |
| Opera | `text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/webp, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1` |  |

Valores para uma imagem
-----------------------

Ao solicitar uma imagem, como por meio de um elemento HTML `<img>`, user-agent geralmente define uma lista específica de tipos de mídia para ser recebida.

| User Agent | Valor | Comentário |
| --- | --- | --- |
| Firefox | `image/webp,*/*` (desde o Firefox 65) `*/*` (desde o Firefox 47) `image/png,image/*;q=0.8,*/*;q=0.5` (antes) | Esse valor pode ser modificado usando o parâmetro `image.http.accept`. fonte |
| Safari | `*/*` |  |
| Chrome | `image/webp,image/apng,image/*,*/*;q=0.8` | fonte |
| Internet Explorer 8 ou anterior | `*/*` | Veja IE and the Accept Header (blog de MSDN da IEInternals) |
| Internet Explorer 9 | `image/png,image/svg+xml,image/*;q=0.8, */*;q=0.5` | Veja Fiddler is better with Internet Explorer 9 (blog de MSDN da IEInternals) |

Valores para um vídeo
---------------------

Quando um vídeo é solicitado, via o elemento HTML `<video>`, a maioria dos navegadores usam valores específicos.

| User Agent | Valor | Comentário |
| --- | --- | --- |
| Firefox anterior a 3.6 | *sem suporte a `<video>`* |  |
| Firefox 3.6 e posterior | `video/webm,video/ogg,video/*;q=0.9,application/ogg;q=0.7,audio/*;q=0.6,*/*;q=0.5` | veja bug 489071 fonte |
| Chrome | `*/*` | fonte |
| Internet Explorer 8 ou anterior | *sem suporte a `<video>`* |  |

Valores para recursos de áudio
------------------------------

Quando um arquivo de áudio é solicitado, como via o elemento HTML `<audio>`, a maioria dos navegadores usam valores específicos.

| User Agent | Value | Comment |
| --- | --- | --- |
| Firefox 3.6 e posterior | `audio/webm,audio/ogg,audio/wav,audio/*;q=0.9,application/ogg;q=0.7,video/*;q=0.6,*/*;q=0.5` | Veja bug 489071 fonte |
| Safari, Chrome | `*/*` | fonte |
| Internet Explorer 8 ou anterior | *sem suporte para `<audio>`* |  |
| Internet Explorer 9 | ? |  |

Valores para scripts
--------------------

Quando um script é solicitado, como via o elemento HTML `<script>`, alguns navegadores usam valores específicos.

| User Agent | Valor | Comentário |
| --- | --- | --- |
| Firefox | `*/*` | Veja bug 170789 |
| Safari, Chrome | `*/*` | fonte |
| Internet Explorer 8 ou anterior | `*/*` | Veja IE and the Accept Header (blog de MSDN da IEInternals) |
| Internet Explorer 9 | `application/javascript, */*;q=0.8` | Veja Fiddler is better with Internet Explorer 9 (blog de MSDN da IEInternals) |

Valores para uma folha de estilo CSS
------------------------------------

Quando uma folha de estilo CSS é solicitada, via o elemento HTML `<link rel="stylesheet">`, a maioria dos navegadores usam valores específicos.

| User Agent | Valor | Comentário |
| --- | --- | --- |
| Firefox 4 | `text/css,*/*;q=0.1` | Veja bug 170789 fonte |
| Internet Explorer 8 ou anterior | `*/*` | Veja IE and the Accept Header (blog de MSDN da IEInternals) |
| Internet Explorer 9 | `text/css` | Veja Fiddler is better with Internet Explorer 9 (blog de MSDN da IEInternals) |
| Safari, Chrome | `text/css,*/*;q=0.1` | fonte |
| Opera 11.10 | `text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/webp, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1` |  |
| Konqueror 4.6 | `text/css,*/*;q=0.1` |  |


510 Not Extended - HTTP

510 Not Extended
================

O código de status da resposta HTTP **`510 Not Extended`** é enviado no contexto do HTTP Extension Framework, definido na RFC 2774.

Na especificação, um cliente pode mandar uma requisição que contenha uma declaração de extensão, que descreve a extensão a ser utilizada. Se o servidor aceitar tal requisição, mas quaisquer extensões descritas na requisição não forem suportadas, o servidor então retorna uma resposta com o código de status **`510`**.

Status
------
```

510 Not Extended
```

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

| Especificação | Título |
| --- | --- |
| RFC 2774, sessão 7: 510 Not Extended | An HTTP Extension Framework |


416 Range Not Satisfiable - HTTP

416 Range Not Satisfiable
=========================

O código de erro de resposta HTTP **`416 Range Not Satisfiable`** indica que o servidor não pode servir as sequências solicitadas. A razão mais provável é que o documento não contenha tais sequências, ou que o valor do cabeçalho `Range`, apesar de sintaticamente correto, não faça sentido.

A mensagem de resposta `416` contém um cabeçalho `Content-Range` indicando uma sequência insatisfatória (que é um `'*'`) seguido por uma `'/'` e o tamanho atual do recurso. E.g. `Content-Range: bytes */12777`

Observando este erro, os navegadores geralmente, ou abortam a operação (por exemplo, o download será considerado não recuperável) ou requisitar o documento inteiro novamente.

Status
------
```

416 Range Not Satisfiable
```

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

| Especificação | Título |
| --- | --- |
| RFC 7233, sessão 4.4: 416 Request Not Satisfiable | 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.

A informação abaixo foi buscada do GitHub da MDN (https://github.com/mdn/browser-compat-data).

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

* `206` `Partial Content`
* `Content-Range`
* `Range`


101 Switching Protocols - HTTP

101 Switching Protocols
=======================

O código de resposta HTTP **`101 Switching Protocols`** indica para qual protocolo o servidor está trocando, conforme solicitado por um cliente que tenha enviado uma mensagem incluindo `Upgrade` (en-US) no cabeçalho da requisição.

O servidor inclui `Upgrade` (en-US) no seu cabeçalho de resposta para indicar para qual protocolo o cliente foi redirecionado. O processo é descrito detalhadamente no artigo Protocol upgrade mechanism (en-US).

Status
------
```

101 Switching Protocols
```

Exemplos
--------

Switching protocols pode ser usado para WebSockets.
```

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
```

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

| Specification | Title |
| --- | --- |
| RFC 7231, sessão 6.2.2: 101 Switching Protocol | Hypertext Transfer Protocol (HTTP/1.1): Semânticas e Conteúdos |

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

* Protocol upgrade mechanism (en-US)
* WebSockets
* `Upgrade` (en-US)
* `426` `Upgrade Required`


508 Loop Detected - HTTP

508 Loop Detected
=================

O código de resposta de erro HTTP **`508 Loop Detected`** pode ser retornado em um contexto do protocolo Web Distributed Authoring and Versioning (WebDAV) .

Indica que o servidor finalizou uma operação porque encontrou um loop infinito enquando processava a requisição com "Depth: infinity". Esse código indica que toda a operação falhou.

Status
------
```

508 Loop Detected
```

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

| Specification | Title |
| --- | --- |
| RFC 5842, sessão 7.2: 508 Loop Detected | Web Distributed Authoring and Versioning |


412 Precondition Failed - HTTP

412 Precondition Failed
=======================

O código de resposta de erro de cliente HTTP **`412 Precondition Failed`** indica que o acesso ao recurso especificado foi negado. Isso acontece com requisições condicionais em métodos que não `GET` ou `HEAD` quando a condição definida pelo cabeçalho `If-Unmodified-Since` ou `If-None-Match` não é satisfeita. Nesse caso, a requisição, geralmente um upload ou modificação de um recurso, não pode ser feita e o código de error de resposta é enviado de volta.

Status
------
```

412 Precondition Failed
```

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

| Especificação | Título |
| --- | --- |
| RFC 7232, sessão 4.2: 412 Precondition Failed | 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.

A informação abaixo foi retirada do GitHub da MDN (https://github.com/mdn/browser-compat-data).

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

* `304`
* `If-Unmodified-Since`
* `If-None-Match`
* `428`


500 Internal Server Error - HTTP

500 Internal Server Error
=========================

Quando o servidor retorna um código de erro (HTTP) 500, indica que encontrou uma condição inesperada e que o impediu de atender à solicitação.

Essa resposta de erro é uma resposta genérica "abrangente". Às vezes, os arquivos log de servidores podem responder com um status code 500 acompanhado de mais detalhes sobre o request para evitar que no futuro erros desse tipo possam voltar a acontecer.

Status
```

500 Internal Server Error
```

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

| Specification | Title |
| --- | --- |
| RFC 7231, sessão 6.6.1: 500 Internal Server Error | 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.

As informações mostradas acima foram extraídas do GitHub da MDN (https://github.com/mdn/browser-compat-data).


406 Not Acceptable - HTTP

406 Not Acceptable
==================

O código de resposta do erro de cliente **`406 Not Acceptable`** indica que o servidor não pode produzir uma resposta que combine com a lista de valores aceitáveis definidas nos cabeçalhos de negociação de conteúdo da requisição proativa, e o servidor é incapaz de produzir uma representação padrão.

Negociação de conteúdo proativa incluem:

* `Accept`
* `Accept-Charset`
* `Accept-Encoding`
* `Accept-Language`

Na prática, esse erro é raramente usado. Ao invés de responder usando esse código de erro, o que poderia ser enigmático ao usuário final e difícil de arrumar, servidores ignoram o cabeçalho relevante e servem a página atual ao usuário. Se assume que mesmo que o usuário não fique completamente feliz, ele irá preferir isso ao invés do código de erro.

Se o servidor retornar este status de erro, o corpo da mensagem deve conter a a lista disponíveis de representações do recurso, possibilitando ao usuário escolher entre elas.

Status
------
```

406 Not Acceptable
```

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

| Especificação | Título |
| --- | --- |
| RFC 7231, sessão 6.5.6: 406 Not Acceptable | 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.

A informação mostrada abaixo foi buscada do MDN's GitHub (https://github.com/mdn/browser-compat-data).

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

* `Accept`
* `Accept-Charset`
* `Accept-Encoding`
* `Accept-Language`
* Negociação de conteúdo HTTP


301 Moved Permanently - HTTP

301 Moved Permanently
=====================

O código de resposta de status de redirecionamento **`301 Moved Permanently`** do protocolo HTTP indica que o recurso requisitado foi movido permanentemente para a URL dada pelo cabeçalho `Localização` headers. Um navegador redireciona para essa página e o motor de busca atualiza os links para o recurso (na linguagem 'SEO', é dito que o "suco do link" ('link-juice') é enviado à nova URL).

Mesmo que a especificação exija que o método (e corpo) não sejam alterados quando o redirecionamento seja executado, nem todos os agentes de usuário são alinhados com isso, você ainda pode encontrar alguns softwares com "bugs" que não o seguem. É recomendado que se use o código 301 somente como resposta para os métodos `GET` ou `Head` e use `308 Permanent Redirect` para `POST`, para proibir explicitamente o uso do método com esse status.

Status
------
```

301 Moved Permanently
```

Exemplo
-------

### Requisição do cliente
```

GET /index.php HTTP/1.1
Host: www.example.org
```

### Resposta do servidor
```

HTTP/1.1 301 Moved Permanently
Location: http://www.example.org/index.asp
```

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

| Especificação | Título |
| --- | --- |
| RFC 7231, sessão 6.4.2: 301 Moved Permanently | 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.

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

* `308 Permanent Redirect`
* `302 Found`, o redirecionamento temporário.


504 Gateway Timeout - HTTP

504 Gateway Timeout
===================

O código de resposta de erro HTTP **`504 Gateway Timeout`** indica que o servidor, enquanto atuando como gateway ou proxy, não conseguiu responder em tempo.

Um Gateway pode referir-se a diferentes elementos de rede e um erro 504 geralmente é algo que você não pode consertar, mas solicitar uma correção no servidor web ou proxy no qual você está tentando acessar.

Estado
------
```

504 Gateway Timeout
```

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

| Especificação | Título |
| --- | --- |
| RFC 7231, sessão 6.6.4: 504 Gateway Timeout | 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.

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

* `502`


451 Unavailable For Legal Reasons - HTTP

451 Unavailable For Legal Reasons
=================================

O código de erro HTTP para o cliente **`451 Unavailable For Legal Reasons`** indica que o recurso solicitado pelo usuário não está disponível por motivos legais, como em uma página web para a qual foi emitida uma ação legal.

Status
------
```

451 Unavailable For Legal Reasons
```

Exemplo
-------

Este exemplo de resposta foi obtida da RFC do IETF (veja abaixo) e contém uma referência à Monty Python's Life of Brian.

**Nota:** o cabeçalho `Link` também pode conter uma relação `rel="blocked-by"` identificando a entidade que solicitou o bloqueio, e não qualquer outra entidade.

Qualquer identificação da entidade responsável pela não disponibilidade do recurso, como o nome da pessoa ou organização que demandou a ação legal que resultou na remoção do conteúdo, deve estar no corpo da resposta, não no link `rel="blocked-by"`.
```

HTTP/1.1 451 Unavailable For Legal Reasons
Link: <https://spqr.example.org/legislatione>; rel="blocked-by"
Content-Type: text/html
```

```
<html>
      <head><title>Unavailable For Legal Reasons</title></head>
      <body>
            <h1>Unavailable For Legal Reasons</h1>
            <p>This request may not be serviced in the Roman Province
            of Judea due to the Lex Julia Majestatis, which disallows
            access to resources hosted on servers deemed to be
            operated by the People's Front of Judea.</p>
     </body>
</html>
```

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

| Epecificação | Título |
| --- | --- |
| RFC 7725: 451 Unavailable For Legal Reasons | An HTTP Status Code to Report Legal Obstacles |

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

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

A informação exibida acima está sendo servida do MDN's GitHub (https://github.com/mdn/browser-compat-data).

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

* Wikipedia: HTTP 451
* Wikipedia: Fahrenheit 451 (which gave this status code its number)


203 Non-Authoritative Information - HTTP

203 Non-Authoritative Information
=================================

A resposta com status HTTP **`203 Non-Authoritative Information`** indica que a requisição foi realizada com sucesso porém o conteúdo foi modificado por um proxy da resposta com status `200` (`OK`) do servidor de origem.

A resposta `203` é similar a resposta com cabeçalho de `Warning` `214`, significando `Transformação Aplicada`, o qual tem uma vantagem adicional que pode ser aplicado a respostas com qualquer código de status.

Status
------
```

203 Non-Authoritative Information
```

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

| Specification | Title |
| --- | --- |
| RFC 7231, sessão 6.3.4: 203 Non-Authoritative Information | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |

See also
--------

* `200`
* Proxy server
* `Warning`


402 Payment Required - HTTP

402 Payment Required
====================

**Experimental:** **Esta é uma tecnologia experimental (en-US)**
Verifique a tabela de compatibilidade entre Navegadores cuidadosamente antes de usar essa funcionalidade em produção.

O código de status HTTP **`402 Payment Required`** é um termo despadronizado para respostas de Status, podendo-se ter usos futuros.

Às vezes, este comando indica que o processo não pôde ser realizado em função de um pagamento não realizado. Originalmente, foi criado para validar uma micro ou grande transação e pode indicar que o método não se realiza até que o cliente efetue o pagamento. Contudo, não existem usos convecionais fixos e sua inserção varia, dependendo do contexto que é posto.

Status
------
```

402 Payment Required
```

Exemplos de resposta
--------------------

```bash
HTTP/1.1 402 Payment Required
Date: Wed, 21 Oct 2015 07:28:00 GMT
```

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

| Especificação | Título |
| --- | --- |
| RFC 7231, sessão 6.5.2: 402 Payment Required | HTTP/1.1: Semântica e contexto |

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

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

* HTTP autenticação


206 Partial Content - HTTP

206 Partial Content
===================

O código de resposta do status de sucesso **`206 Partial Content`** indica que a requisição teve sucesso e o corpo contém a sequência (em bytes) dos dados, como descrito no cabeçalho `Range` da requisição.

Se existe somente uma sequência, o `Content-Type` de toda a resposta é colocado para o tipo do documento, e o cabeçalho `Content-Range` é provido.

Se várias sequências são mandadas como resposta, o `Content-Type` é colocado para `multipart/byteranges` e cada fragmento cobre uma sequência, com `Content-Range` e `Content-Type` descrevendo-os.

Status
------
```

206 Partial Content
```

Exemplos
--------

Uma resposta contendo uma única sequência:
```

HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 2015 06:25:24 GMT
Last-Modified: Wed, 15 Nov 2015 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif

... 26012 bytes de dados parciais de uma imagem ...
```

Uma resposta contendo várias sequências:
```

HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 2015 06:25:24 GMT
Last-Modified: Wed, 15 Nov 2015 04:58:08 GMT
Content-Length: 1741
Content-Type: multipart/byteranges; boundary=String_separator

--String_separator
Content-Type: application/pdf
Content-Range: bytes 234-639/8000

...a primeira sequência...
--String_separator
Content-Type: application/pdf
Content-Range: bytes 4590-7999/8000

...a segunda sequência
--String_separator--
```

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

| Especificação | Título |
| --- | --- |
| RFC 7233, sessão 4.1: 206 Partial Content | 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`
* `Content-Range`
* `Content-Type`


501 Not Implemented - HTTP

501 Not Implemented
===================

O código de resposta HTTP **`501 Not Implemented`** indica que o servidor não suporta a funcionalidade requerida para completar a requisição. Esta é a resposta apropriada para quando o servidor não reconhece o método requisitado e não tem capacidade de suporta-lo para nenhum recurso. Os únicos métodos de requisição que os servidores suportam obrigatóriamente ( e, portanto, isso não deve retornar este código) são `GET` e `HEAD`.

**Nota:** **Notas:**

* A 501 error is not something you can fix, but requires a fix by the web server you are trying to access.
* Uma resposta 501 é cacheada por padrão, ou seja, a menos que os cabeçalhos de cache indiquem outra forma.

Status
------
```

501 Not Implemented
```

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

| Especificação | Título |
| --- | --- |
| RFC 7231, sessão 6.6.2: 501 Not Implemented | 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.

The information shown below has been pulled from MDN's GitHub (https://github.com/mdn/browser-compat-data).


407 Proxy Authentication Required - HTTP

407 Proxy Authentication Required
=================================

O código de resposta HTTP \*\*`407 Proxy Authentication Required` \*\*indica um erro do lado cliente, informando que uma solicitação não está sendo bem aplicada. Isso ocorre porque falta a validar as credencias de autenticação para um proxy server que intermedia o navegador e o servidor que pode acessar o recurso solicitado.

Este erro é enviado com um cabeçalho `Proxy-Authenticate` que contém informações de como fazer uma autorização correta.

Status
------
```

407 Proxy Authentication Required
```

Exemplo de resposta
-------------------
```

HTTP/1.1 407 Proxy Authentication Required
Date: Wed, 21 Oct 2015 07:28:00 GMT
Proxy-Authenticate: Basic realm="Access to internal site"
```

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

| Epecificação | Título |
| --- | --- |
| RFC 7235, sessão 3.2: 407 Proxy Authentication Required | HTTP/1.1: Authentication |

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

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

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

* Autenticação HTTP
* `WWW-Authenticate`
* `Authorization`
* `Proxy-Authorization`
* `Proxy-Authenticate`
* `401`, `403`


300 Multiple Choices - HTTP

300 Multiple Choices
====================

O código de resposta HTTP do status de redirecionamento **`300 Multiple Choices`** indica que a requisição tem uma ou mais possíveis respostas. O agente de usuário ou o usuário devem escolher uma delas. Como não há forma padrão de se escolher uma das respostas, esse código de resposta é raramente usado.

Se o servidor tem uma escolha de preferência, ele deve gerar um cabeçalho `Localização`.

Status
------
```

300 Multiple Choices
```

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

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

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

* `301` `Moved Permanently`
* `302` `Found`, o redirecionamento temporário
* `308` `Permanent Redirect`


505 HTTP Version Not Supported - HTTP

505 HTTP Version Not Supported
==============================

O código de resposta de status HTTP **`505 HTTP Version Not Supported`** indica que a versão HTTP utilizada na requisição não é suportada pelo servidor.

Status
------
```

505 HTTP Version Not Supported
```

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

| Especificação | Título |
| --- | --- |
| RFC 7231, sessão 6.6.6: 505 HTTP Version Not Supported | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |

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

* `Upgrade` (en-US)


202 Accepted - HTTP

202 Accepted
============

O código resposta HyperText Transfer Protocol (HTTP) **`202 Accepted`** indica que a requisição foi recebida, mas não pode atuar ainda. Ela é sem compromisso, significando que não há maneira de o HTTP enviar posteriormente uma resposta assíncrona indicando a saída do processamento da requisição. A intenção desta resposta é para os casos onde outro processo ou, ainda, servidor lida com a requisição ou para processamentos *batch.*

Status
------
```

202 Accepted
```

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

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

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

* `Accept`


304 Not Modified - HTTP

304 Not Modified
================

O código de resposta HTTP de redirecionamento do cliente **`304`** **`Not Modified`** indica que não há necessidade de retransmitir a requisição de recursos. É um redirecionamento implícito para o recurso em cache. Isto ocorre quando o método de requisição é safe, assim como uma requisição `GET` ou `HEAD`, ou quando a requisição é condicional e usa um cabeçalho `If-None-Match` ou `If-Modified-Since`.

A resposta equivalente `200` `OK` teria incluso os cabeçalhos `Cache-Control`, `Content-Location`, `Date`, `ETag`, `Expires`, e `Vary`.

**Nota:** Vários painéis de rede de ferramentas de desenvolvedor dos navegadores criam requisições irrelevantes direcionando para respostas `304`, logo este acesso ao cache local é visível aos desenvolvedores.

Status
------
```

304 Not Modified
```

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

| Specification | Title |
| --- | --- |
| RFC 7232, sessão 4.1: 304 Not Modified | 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.

Notas de Compatibilidade
------------------------

* O comportamento do navegador difere se em conexões persistentes a resposta erroneamente incluir um corpo. Leia 204 No Content para mais detalhes.
Veja também
-----------

* `If-Modified-Since`
* `If-None-Match`


403 Forbidden - HTTP

403 Forbidden
=============

O código de resposta de status de erro do cliente HTTP **`403 Forbidden`** indica que o servidor entendeu o pedido, mas se recusa a autorizá-lo.

Esse status é semelhante ao `401` , mas neste caso, a re-autenticação não fará diferença. O acesso é permanentemente proibido e vinculado à lógica da aplicação (como uma senha incorreta).

Status
------
```

403 Forbidden
```

Exemplo de resposta
-------------------
```

HTTP/1.1 403 Forbidden
Date: Wed, 21 Oct 2015 07:28:00 GMT
```

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

| Especificação | Título |
| --- | --- |
| RFC 7231, sessão 6.5.3: 403 Proibido | HTTP/1.1: Semântica e Conteúdo |

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

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

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

* `401`


511 Network Authentication Required - HTTP

511 Network Authentication Required
===================================

O código de erro HTTP para o cliente **`511 Network Authentication Required`** indica que o cliente precisa realizar uma autenticação para utilizar a rede.

Esse status não é gerado pelos servidores de origem, mas pela interceptação de proxies que controlam o acesso à rede.

Às vezes, as operadoras de rede exigem alguma autenticação, aceitação de termos ou outra interação do usuário antes de conceder acesso (por exemplo, em um cyber café ou em um aeroporto). Eles geralmente identificam clientes que não o fizeram usando seus endereços de Controle de Acesso à Mídia(MAC)

Status
------
```

511 Network Authentication Required
```

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

| Especificação | Título |
| --- | --- |
| RFC 6585, sessão 6: 511 Network Authentication Required | Códigos adicionais de estado HTTP |

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

* Proxy server


308 Permanent Redirect - HTTP

308 Permanent Redirect
======================

O código de resposta do status de redirecionamento **`308 Redirecionamento Permanente`** do Protocolo de Transferência de Hipertexto (HTTP) indica que o recurso requisitado foi movido definitivamente para o URL dado pelo cabeçalho `Localização`. O navegador redireciona para essa página e o motor de busca atualiza os seus links para o recurso (na linguagem 'SEO', é dito que o "suco do link" ('link-juice') é enviado à nova URL).

O método de requisição e o corpo não será alterado, onde talvez o status `301` seja modificado incorretamente para o método `GET`.

>
> \*\*Nota:\*\*Algumas aplicações Web podem usar o `308 Permanent Redirect` de forma não convencional e para outros propósitos. Por exemplo, Google Drive usa a resposta `308 Resume Incomplete` para indicar ao cliente quando um upload incompleto parou.[1]
>
>
>

Status
------
```

308 Redirecionamento Permanente
```

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

| Specification | Title |
| --- | --- |
| RFC 7538, sessão 3: 308 Permanent Redirect | The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect) |

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

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

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

* `301 Moved Permanently`
* `302 Found`, o redirecionamento temporário


100 Continue - HTTP

100 Continue
============

O Status HTTP **`100 Continue`** indica que até o momento tudo está OK e que o cliente pode continuar com a requisição ou ignorar caso já tenha terminado.

Para ter uma verificação pelo servidor o cliente deve enviar o header `Expect`: `100-continue` na requisição inicial e receber o status `100 Continue` antes de enviar o body da requisição.

Status
------
```

100 Continue
```

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

| Specification | Title |
| --- | --- |
| RFC 7231, sessão 6.2.1: 100 Continue | 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.

See also
--------

* `Expect`
* `417`


417 Expectation Failed - HTTP

417 Expectation Failed
======================

O codigo de erro de cliente HTTP **`417 Expectation Failed`** indica que a expectativa enviada no cabeçalho da requisição `Expect` não foi suprida.

Veja o cabeçalho `Expect` para mais detalhes.

Estado
------
```

417 Expectation Failed
```

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

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

Ver também
----------

* `Expect`


426 Upgrade Required - HTTP

426 Upgrade Required
====================

O status HTTP **`426 Upgrade Required`** indica que o servidor recusa o processamento da requisição usando o protocolo atual mas poderá ser processado caso o cliente atualize para um protocolo diferente.

O servidor envia uma header `Upgrade` (en-US) com esta resposta para indicar qual o protocolo necessário.

Status
------
```

426 Upgrade Required
```

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

HTTP/1.1 426 Upgrade Required
Upgrade: HTTP/2.0
Connection: Upgrade
Content-Length: 53
Content-Type: text/plain

This service requires use of the HTTP/2.0 protocol
```

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

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

Ver também
----------

* `Upgrade` (en-US)
* `101` `Switching Protocol`


422 Unprocessable Entity - HTTP

422 Unprocessable Entity
========================

O codigo de resposta HTTP **`422 Unprocessable Entity`** indica que o servidor entende o tipo de conteúdo da entidade da requisição, e a sintaxe da requisição esta correta, mas não foi possível processar as instruções presentes.

**Aviso:** **Importante**: O cliente não deve repetir esta requisição sem modificações.

Status
------
```

422 Unprocessable Entity
```

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

| Especificação | Título |
| --- | --- |
| RFC 4918, sessão 11.2: 422 Unprocessable Entity | HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV) |


413 Payload Too Large - HTTP

413 Payload Too Large
=====================

O código de resposta HTTP **`413 Payload Too Large`** indica que a carga da requisição é mais larga que os limites estabelecidos pelo servidor; o servidor pode encerrar a conexão ou retornar `Retry-After` no campo de cabeçalho.

Status
------
```

413 Payload Too Large
```

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

| Specification | Title |
| --- | --- |
| RFC 7231, sessão 6.5.11: 413 Payload Too Large | Hypertext Transfer Protocol (HTTP/1.1):Semânticas e Conteúdo |

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

* `Connection`
* `Retry-After`


204 No Content - HTTP

204 No Content
==============

O código de resposta HTTP de status de sucesso **`204 No Content`** indica que a solicitação foi bem sucedida e o cliente não precisa sair da página atual. Uma resposta `204` é armazenada em cache por padrão. Um cabeçalho `ETag` está incluso na resposta.

O caso de uso comum é retornar `204` como resultado de uma solicitação `PUT`, atualizando um recurso, sem alterar o conteúdo atual da página exibida para o usuário. Se o recurso for criado, `201` `Created` será retornado. Se a página for alterada para a página recém-atualizada, o `200` deve ser usado em vez disso.

Status
------
```

204 No Content
```

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

| Especificação | Título |
| --- | --- |
| RFC 7231, sessão 6.3.5: 204 No Content | 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
------------------------

* Embora este código de status seja destinado a descrever uma resposta sem corpo, os servidores podem incluir dados erroneamente após os cabeçalhos. O protocolo permite que os agentes do usuário variem em como eles processam essas respostas (a discussão sobre este texto da especificação pode ser encontrada aqui). Isso é observável em conexões persistentes, onde o corpo inválido pode incluir uma resposta distinta a uma solicitação subseqüente.
 O Apple Safari rejeita qualquer desses dados. O Google Chrome e o Microsoft Edge descartam até quatro bytes inválidos que precedem uma resposta válida. O Firefox tolera mais de um kilobyte de dados inválidos que precedem uma resposta válida.
Veja também
-----------

* Métodos de requisições HTTP


503 Service Unavailable - HTTP

503 Service Unavailable
=======================

O código de resposta de erro de servidor **`503 Service Unavailable`** do HTTP indica que o servidor não está pronto para lidar com a requisição.

Causas comuns são um servidor que está em manutenção ou sobrecarregado. Esta resposta deve ser usada para condições temporárias, e o cabeçalho HTTP `Retry-After` deve, se possível, conter o tempo estimado para restabelecimento do serviço.

**Nota:** Juntamente com esta resposta deve ser enviada uma página de fácil compreensão para explicar o problema.

Os cabeçalhos relativos ao armazenamento em cache que são enviados juntamente com esta resposta devem ser atendidos, pois um status 503 geralmente é uma condição temporária e tal resposta não deve ser armazenada em cache.

Status
------
```

503 Service Unavailable
```

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

| Especificação | Título |
| --- | --- |
| RFC 7231, sessão 6.6.4: 503 Service Unavailable | 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.

A informação mostrada acima está sendo servida do MDN's GitHub (https://github.com/mdn/browser-compat-data).

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

* `Retry-After`
* 503 Service Unavailable


405 Method Not Allowed - HTTP

405 Method Not Allowed
======================

Este status de resposta indica que o verbo HTTP utilizado não é suportado, por exemplo: a requisição ocorre por meio de um get, porém o único método disponível é o post.Curiosidade: Existem um método chamado OPTIONS que retorna todos os verbos suportados naquela requisiçãoobs: ele também pode não ser permitido

Status
------
```

405 Method Not Allowed
```

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

| Specification | Title |
| --- | --- |
| RFC 7231, sessão 6.5.5: 405 Method Not Allowed | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |

See also
--------

* `Allow`


302 Found - HTTP

302 Found
=========

O código de estado HyperText Transfer Protocol (HTTP) **`302 Found`** indica que o recurso foi temporariamente movido para a URL informada pelo cabeçalho `Localização`. Os navegadores redirecionar para essa página porém os motores de busca não atualizam o link inicial.

Mesmo que a requisição requer que o método (e o corpo) não sejam alterados quando o redirecionamento é feito, nem todos os user-agent entram em conformidade - ainda é comum encontrar softwares com bugs neste quesito. Por isso, é recomendado habilitar o código `302` somente em resposta aos métodos `GET` ou `HEAD` e utilizar o método `307 Temporary Redirect` em outros casos, já que a troca de método é expressamente proibida nesse caso.

Em casos onde você deseja que o método utilizado altere para `GET`, utilize `303 See Other`. Isto é útil quando você deseja dar uma resposta a um método `PUT` que não seja um recurso, mas uma mensagem de confirmação, como por exemplo: 'você enviou XYZ com sucesso'.

Status
------
```

302 Encontrado
```

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

| Especificação | Título |
| --- | --- |
| RFC 7231, sessão 6.4.3: 302 Found | 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.

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

* `307 Temporary Redirect`, o equivalente a esse código de estado quando o método utilizado nunca é alterado.
* `303 See Other`, um redirecionamento temporário que altera o método utilizado para `GET`.
* `301 Moved Permanently`, o redirecionamento permanente.


428 Precondition Required - HTTP

428 Precondition Required
=========================

O codigo de resposta HTTP **`428 Precondition Required`** indica que o servidor precisa que a requisição seja condicional (en-US).

Normalmente, isto significa que um cabeçalho pré-requisito, como o `If-Match`, **está faltando**.

Quando o cabeçalho pré-requisito **não é o mesmo** esperado pelo servidor, a resposta deve ser `412` `Precondition Failed`.

Status
------
```

428 Precondition Required
```

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

| Especificação | Título |
| --- | --- |
| RFC 6585, sessão 3: 428 Precondition Required | Additional HTTP Status Codes |

Ver também
----------

* HTTP conditional requests (en-US)
* `If-Match`
* `412`


507 Insufficient Storage - HTTP

507 Insufficient Storage
========================

O código de resposta de status HTTP **`507 Insufficient Storage`** pode ser usado no contexto do protocolo Web Distributed Authoring and Versioning (WebDAV) (veja RFC 4918).

Isso indica que o método não pode ser executado porque o servidor não pode salvar a representação necessária para completar a requisição com sucesso.

Status
------
```

507 Insufficient Storage
```

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

| Especificação | Título |
| --- | --- |
| RFC 4918, sessão 11.5: 507 Insufficient Storage | Web Distributed Authoring and Versioning |


200 OK - HTTP

200 OK
======

O código HTTP **`200 OK`** é a resposta de status de sucesso que indica que a requisição foi bem sucedida. Uma resposta 200 é cacheável por padrão.

O significado de sucesso depende do método de requisição HTTP:

* `GET`: O recurso foi carregado e transmitido no corpo da mensagem.
* `HEAD`: Os cabeçalhos da entidade estão no corpo da mensagem.
* `POST`: O recurso descrevendo o resultado da ação é transmitido no corpo da mensagem.
* `TRACE`: O corpo da mensagem contém a mensagem da requisição tal qual foi recebida pelo servidor.

O resultado de sucesso de um `PUT` ou `DELETE` geralmente não são `200 OK`, e sim `204` `No Content` (ou `201` `Created` quando o recurso é carregado pela primeira vez).

Status
------
```

200 OK
```

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

| Especificação | Título |
| --- | --- |
| RFC 7231, sessão 6.3.1: 200 OK | 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.

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

* HTTP request methods


401 Unauthorized - HTTP

401 Unauthorized
================

O código de resposta de status de erro do cliente HTTP **`401 Unauthorized`** indica que a solicitação não foi aplicada porque não possui credenciais de autenticação válidas para o recurso de destino.

Esse status é enviado com um cabeçalho `WWW-Authenticate` que contém informações sobre como autorizar corretamente.

Esse status é semelhante a `403`, mas neste caso, a autenticação é possível.

Status
------
```

401 Unauthorized
```

Exemplo de resposta
-------------------
```

HTTP/1.1 401 Não autorizado
Date: Wed, 21 Oct 2015 07:28:00 GMT
WWW-Authenticate: Basic realm="Acesso intermediário ao site"
```

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

| Especificação | Título |
| --- | --- |
| RFC 7235, sessão 3.1: 401 Não autorizado | HTTP/1.1: Autenticação |

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

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

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

* HTTP authentication
* `WWW-Authenticate`
* `Authorization`
* `Proxy-Authorization`
* `Proxy-Authenticate`
* `403`, `407`


415 Unsupported Media Type - HTTP

415 Unsupported Media Type
==========================

O erro HTTP **`415 Unsupported Media Type`** do cliente indica que o servidor se recusou a aceitar a requisição porque o formato do payload não é um formato suportado.

O problema do formato por ter ocorrido pelos valores indicados no `Content-Type` ou `Content-Encoding`, ou pelo resultado da inspeção do dado em si.

Status
------
```

415 Unsupported Media Type
```

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

| Especificações | Título |
| --- | --- |
| RFC 7231, sessão 6.5.13: 415 Unsupported Media Type | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |

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

* `Content-Type`
* `Content-Encoding`
* `Accept`


409 Conflict - HTTP

409 Conflict
============

O status de resposta **`409 Conflict`** indica que a solicitação atual conflitou com o recurso que está no servidor.

Conflitos são mais frequentes quando usado o método `PUT`. Por exemplo, você pode receber uma resposta 409 quando fizer upload de um arquivo que é mais antigo do que já existe no servidor, resultando em conflito de versão.

Status
------
```

409 Conflito
```

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

| Especificação | Título |
| --- | --- |
| RFC 7231, sessão 6.5.8: 409 Conflict | Protocolo de Transferência de Hypertexto (HTTP/1.1): Semântica e Conteúdo |

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

* `PUT`


411 Length Required - HTTP

411 Length Required
===================

O código de resposta **`411 Length Required`** de erro de cliente do Protocolo de Transferência de HyperTexto (HTTP) indica que o servidor se nega a aceitar a requisição sem um cabeçalho `Content-Length` definido.

>
> \*\*Nota:\*\*pela especificação, quando envia dados em uma série de blocos, o cabeçalho `Content-Length` é omitido e no início de cada bloco você precisa adicionar o tamanho do bloco corrente no formato hexadecimal. Veja `Transfer-Encoding` para mais detalhes.
>
>
>

Status
------
```

411 Length Required
```

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

| Specification | Title |
| --- | --- |
| RFC 7231, sessão 6.5.10: 411 Length Required | Protocolo de transferência de Hipertexto (HTTP/1.1): Semântica e Conteúdo |

See also
--------

* `Content-Length`
* `Transfer-Encoding`


103 Early Hints - HTTP

103 Early Hints
===============

O código de informação de status de resposta HTTP **`103 Early Hints`** é destinado principalmente a ser usado com o cabeçalho `Link` para permitir ao agente do usuário começar pré-carregamento de recursos enquanto o servidor ainda está preparando uma resposta.

Sintaxe
-------
```

103 Early Hints
```

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

| Especificação | Status | Comentários |
| --- | --- | --- |
| RFC 8297: 103 Early Hints | IETF RFC | Definição inicial |

Comptabilidade de navegador
---------------------------

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

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

* `Link`


414 URI Too Long - HTTP

414 URI Too Long
================

O código de resposta **`414 URI Too Long`** indica que o tamanho da URI requisitada pelo cliente é maior do que o tamanho que o servidor aceita interpretar.

Existem algumas raras condições em que isso pode ocorrer:

* quando um cliente converteu de forma imprópria uma requisição `POST` para uma requisição `GET` com uma sequência de informações muito grande,
* quando o cliente caiu em um loop de redirecionamentos (por exemplo, um redirecionamento de uma URI prefixada que aponta para um sufixo de si mesmo),
* ou quando o servidor está sob ataque por um cliente tentando explorar potenciais falhas de segurança.
Status
------
```

414 URI Too Long
```

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

| Especificação | Título |
| --- | --- |
| RFC 7231, sessão 6.5.12: 414 URI Too Long | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |

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

* URI


425 Too Early - HTTP

425 Too Early
=============

**Experimental:** **Esta é uma tecnologia experimental (en-US)**
Verifique a tabela de compatibilidade entre Navegadores cuidadosamente antes de usar essa funcionalidade em produção.

O status HTTP **`425 Too Early`** indica que o servidor não quer correr o risco de processar uma requisição que pode ser repetida, o que cria um potencial risco para ataques de repetição.

Status
------
```

425 Too Early
```

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

| Especificação | Título |
| --- | --- |
| RFC 8470, sessão 5.2: 425: Early Data | Using Early Data in HTTP |

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

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


408 Request Timeout - HTTP

408 Request Timeout
===================

`A resposta 408 Request Timeout` significa que o servidor irá encerrar essa conexão em desuso. É enviado a uma conexão parada por alguns servidores, *mesmo sem nenhuma requisição feita anteriormente pelo cliente*.

O servidor deve enviar no cabeçalho de resposta "close" `Connection` já que `408` implica que o servidor decidiu encerrar a conexão ao invés de continuar aguardando.

Essa resposta está sendo mais usada desde que alguns browsers como Chrome, Firefox 27+, e IE9, usam o mecanismo "HTTP pre-connection" para acelerar a navegação.

>
> \*\*Nota:\*\*alguns servidores simplesmente encerram a conexão sem enviar esssa mensagem.
>
>
>

Status
------
```

408 Request Timeout
```

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

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

Veja Também
-----------

* `Connection`
* `X-DNS-Prefetch-Control`


410 Gone - HTTP

410 Gone
========

O código de resposta HTTP **`410 Gone`** de erro do cliente indica que o acesso ao recurso não está mais disponível no servidor de origem, e que esta condição tende a ser permanente.

Se você não sabe se a ausência do recurso é temporária ou permanente, o código de status `404` deverá ser utilizado.

>
> \*\*Nota:\*\*Uma resposta 410 response é armazenada em cache por default.
>
>
>

Status
------
```

410 Gone
```

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

| Especificação | Título |
| --- | --- |
| RFC 7231, sessão 6.5.9: 410 Gone | 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.

A informação mostrada abaixo está sendo servida do MDN's GitHub (https://github.com/mdn/browser-compat-data).

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

* `404`


205 Reset Content - HTTP

205 Reset Content
=================

O código de estado HTTP **`205 Reset Content`** informa ao cliente para reconfigurar a visualização do documento, para, por exemplo, limpar o conteúdo de um formulário, redefinir um estado da tela ou atualizar a interface do usuário.

Status
------
```

205 Reset Content
```

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

| Specification | Title |
| --- | --- |
| RFC 7231, sessão 6.3.6: 205 Reset Content | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |

Compatibility Notes
-------------------

* O comportamento do Browser é diferente se a resposta de forma errada incluir um Body nas conexões persistentes, veja 204 No Content para mais detalhes.
See also
--------

* `204` No Content


502 Bad Gateway - HTTP

502 Bad Gateway
===============

O código de erro HTTP **`502 Bad Gateway`** retornado pelo servidor indica que ele, enquanto atuando como um servidor intermediário (*gateway* ou *proxy*), recebeu uma resposta inválida do servidor para o qual a requisição foi encaminhada (*upstream server*).

**Nota:** Um *Gateway* pode se referir a coisas diferentes na rede e um erro 502 geralmente não é algo que você possa corrigir, mas requer uma correção por parte do servidor web ou dos proxies através dos quais você está tentando obter acesso.

Status
------
```

502 Bad Gateway
```

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

| Especificação | Título |
| --- | --- |
| RFC 7231, sessão 6.6.3: 502 Bad Gateway | 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.

As informações mostradas acima foram extraídas do GitHub do MDN (https://github.com/mdn/browser-compat-data).

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

* `504`


404 Not Found - HTTP

404 Not Found
=============

A resposta de erro **`404 Not Found`** indica que o servidor não conseguiu encontrar o recurso solicitado. Normalmente, links que levam para uma página 404 estão quebrados ou desativados e podem estar sujeitos a link rot.

Um código 404 não indica se o recurso está indisponível temporariamente ou se o recurso foi permanentemente removido. Mas, se esse for o caso, o ideal é utilizar o código `410` (Gone).

Status
------
```

404 Not Found
```

Páginas de erro personalizadas
------------------------------

Vários sites customizam o design de uma página 404 para facilitar a usabilidade e ajudá-lo em o que fazer em seguida. Servidores apache podem ser configurados usando um arquivo `.htaccess` e um pequeno código como o seguinte.

```bash
ErrorDocument 404 /notfound.html
```

Para um exemplo de uma página 404 personalizada, veja MDN's 404 page.

**Nota:** Usar um design personalizado é uma boa ideia, se usado em moderação. Sinta-se livre para fazer a sua página 404 divertida, mas tome cuidado para não confundir seus usuários.

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

| Especificação | Título |
| --- | --- |
| RFC 7231, sessão 6.5.4: 404 Not Found | 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.

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

* `410`
* Wikipedia: HTTP 404