Recursos ocultos de HTTP

Quais recursos ocultos do HTTP você acha que vale a pena mencionar?

Por recursos ocultos, quero dizer recursos que já fazem parte do padrão, mas amplamente desconhecidos ou não utilizados.

Apenas um recurso por resposta, por favor.

Deve ser o código de status 418 I'm a bule de chá , parte do Hyper Text Coffee Pot Control Protocol (uma extensão para HTTP). Me faz rir o tempo todo.

2.3.2 418 Eu sou um bule

Qualquer tentativa de preparar café com um bule de chá deve resultar no código de erro "418 I'm a bule". O corpo da entidade resultante PODE ser curto e robusto.

O fato de que o referenciador foi digitado incorretamente e foi decidido que o erro ortográfico deve ser mantido.

Resposta óbvia: métodos PUT, DELETE, TRACE, OPTIONS, CONNECT

A maioria das pessoas conhece os métodos GET e POST porque é isso que eles usam ao construir formulários. Os navegadores também usam muito o HEAD. Os outros métodos são muito menos conhecidos; eles são usados ​​principalmente por aplicativos mais específicos.

Alguém já viu o 402 Pagamento Obrigatório ?

204 Sem conteúdo

Pensei que 204 fosse apenas se você não tivesse conteúdo para exibir, mas a especificação parece que há um comportamento adicional de que o agente do usuário "não altere a visualização do documento".

De acordo com o HOWTO: Configure o Apache para retornar um HTTP 204 (sem conteúdo) para AJAX

FWIW, o Google realmente faz algo semelhante. Cada vez que um usuário clica em um link em seus resultados de pesquisa, o Google executa um ping para registrar o clique; o código de resposta do ping é um HTTP 204.

Além disso, 204 Sem conteúdo propõe que essa é uma boa técnica para "bugs da web" ou "beacons" se você quiser economizar até o último byte de tráfego de rede possível.

Código de Resposta410 Gone :

(...) os proprietários do servidor desejam que os links remotos para esse recurso sejam removidos. (...)

Web spiders (mais notavelmente o Google) irão desindexar (geralmente no próximo rastreamento) uma página que começa a retornar 410.

No conteúdo dinâmico, use o cabeçalho Last_Modified ou ETag

Às vezes, você tem conteúdo dinâmico que pode ser grande e / ou caro para gerar e que pode não mudar de solicitação para solicitação. Você pode adicionar um cabeçalho Last_Modified ou ETag à sua resposta gerada.

No topo de seu caro código dinâmico, você pode usar If_Modified_Since ou If_None_Match para determinar se o solicitante de conteúdo já está atualizado. Se estiver, altere o status da resposta para "304 Unmodified" e encerre a solicitação.

Algumas tecnologias do lado do servidor fornecem esses recursos formalmente, mas você pode fazer o acima mesmo no modesto ASP-Classic.

Observe que isso difere da configuração dos cabeçalhos Cache-Control, Expires, pois garante que o cliente sempre tenha as informações mais recentes sob solicitação.

Você pode solicitar o retorno de uma resposta HTTP (grande) (por exemplo, download de arquivo) usando Rangee If-Rangesolicitar cabeçalhos com, respectivamente, o intervalo de bytes especificado e o identificador de arquivo exclusivo ou o carimbo de data / hora de modificação do arquivo. Isso é possível se o servidor tiver enviado os cabeçalhos de resposta Accept-Ranges: bytese ETagou Last-Modifiedna resposta inicial com, respectivamente, a notificação de que o servidor oferece suporte a solicitações de intervalo de bytes, o identificador de arquivo exclusivo e o carimbo de data / hora de modificação do arquivo.

A resposta inicial pode ser semelhante a ( ETaggeralmente é composto do nome do arquivo, tamanho e data e hora da última modificação):

Accept-Ranges: bytes
ETag: file.ext_1234_1234567890
Content-Range: bytes 0-1233/1234

Quando o download é abortado em, por exemplo, 1 KB (1024 bytes), o cliente pode retomá-lo da seguinte maneira:

If-Range: file.ext_1234_1234567890
Range: bytes=1024-

Que deve retornar esta resposta com os bytes apropriados no corpo:

Accept-Ranges: bytes
ETag: file.ext_1234_1234567890
Content-Range: bytes 1024-1233/1234

ReST tenta empurrar o HTTP até seus limites como um protocolo de interface.

Não é um recurso oculto , mas olhando para APIs ReST bem definidas, pode-se obter uma boa noção de como o HTTP deve funcionar e encontrar exemplos maravilhosos do que pode ser alcançado com a simples combinação de métodos HTTP, códigos de status e cabeçalhos para e para lá.

Trailer (em contraste com Header)

O protocolo permite que você defina seus próprios campos personalizados. Eles podem ser usados ​​para transportar outras informações, se você não quiser usar cookies para isso.

Status HTTP 100 (continuar)

Um cliente pode enviar uma mensagem de solicitação com um corpo de solicitação para determinar se o servidor de origem está disposto a aceitar a solicitação.

Em alguns casos, pode ser inapropriado ou altamente ineficiente para o cliente enviar o corpo se o servidor rejeitar a mensagem sem olhar para o corpo.

Pode ser usado para evitar o tráfego de clientes invasores ... e / ou onde a largura de banda é um bem precioso.

No entanto, para o uso completo desse recurso, existem alguns critérios para Cliente, Servidores e Proxies HTTP1.1. Consulte HTTP / 1.1 RFC 2616 para obter mais informações sobre Conexões HTTP.

Códigos de status :

• Quando o URI http://www.domain.invalid/index.php?id=44 é chamado, se a query ( id=44) não pôde retornar um recurso, por que não retornar um código de status 404?
• Quando URI http://www.domain.invalid/index.php?id=foo é chamado enquanto idaceita apenas inteiros, por que não retornar um código de status 400?
• Por que, quando você insere o login / senha incorretos, quase todos os aplicativos web retornam uma mensagem como "Falha na autenticação" com o código de status 200(ok, sem problemas, você fez bem) ao invés de 401?

Sim, os códigos de status parecem ser uma espécie de funcionalidade secreta do HTTP para alguns desenvolvedores web ... Mas eu me pergunto se o mais oculto de todos os "recursos" desse protocolo não é seu RFC !