recursal/MDN huggingface dataset:
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
======

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
====

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
=====

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
===

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
====

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`
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
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
=========================

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
=======================

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
=================

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
=======================

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
=========================

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
==================

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
=====================

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
===================

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
=================================

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)