304 Not Modified

Uma solicitação GET ou HEAD condicional foi recebida e teria resultado em uma resposta 200 OK se não fosse pelo fato de que a condição foi avaliada como falsa.

Em outras palavras, não há necessidade de o servidor transferir uma representação do recurso de destino porque a solicitação indica que o cliente, que tornou a solicitação condicional, já possui uma representação válida; o servidor está, portanto, redirecionando o cliente para fazer uso dessa representação armazenada como se fosse a carga de uma resposta 200 OK

O servidor que gera uma resposta 304 DEVE gerar qualquer um dos seguintes campos de cabeçalho que teriam sido enviados em uma resposta 200 OK para a mesma solicitação: Cache-Control, Content-Location, Date, ETag, Expires e Vary.

Uma vez que o objetivo de uma resposta 304 é minimizar a transferência de informações quando o destinatário já tem uma ou mais representações em cache, um remetente NÃO DEVE gerar metadados de representação além dos campos listados acima, a menos que esses metadados existam com o propósito de orientar as atualizações de cache (por exemplo, Última modificação pode ser útil se a resposta não tiver um campo ETag).

Os requisitos em um cache que recebe uma resposta 304 são definidos na Seção 4.3.4 do RFC7234. Se a solicitação condicional foi originada de um cliente de saída, como um agente de usuário com seu próprio cache enviando um GET condicional para um proxy compartilhado, então o proxy DEVERIA encaminhar a 304 resposta a esse cliente.

Uma resposta 304 não pode conter um corpo de mensagem; sempre termina com a primeira linha vazia após os campos do cabeçalho.