Que os códigos diferentes da resposta HTTP significam?

Opções de download

PDF (82.1 KB)
Ver no Adobe Reader em vários dispositivos
ePub (76.6 KB)
Ver em vários aplicativos no iPhone, iPad, Android, Sony Reader ou Windows Phone
Mobi (Kindle) (67.5 KB)
Ver no dispositivo Kindle ou no aplicativo Kindle em vários dispositivos

Atualizado:12 de Agosto de 2014

ID do documento:118217

Linguagem imparcial

O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.

Sobre esta tradução

A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.

Índice

Pergunta:

Que os códigos diferentes da resposta HTTP significam?

Ambiente: Ferramenta de segurança da Web de Cisco (WSA) que executa alguma versão de AsyncOS

O HTTP tem sempre um pedido do cliente e uma resposta de servidor. As respostas de servidor são classificadas por um código numérico da resposta. Os códigos da resposta indicam as razões atrás dos pedidos do HTTP bem sucedidos e falhados.

Para a informação detalhada completa em relação aos códigos da resposta HTTP, veja por favor o RFC 2616 (HTTP), a seção 10.

Estão abaixo os detalhes em relação ao código o mais comum da resposta que você é provável ser executado em:

códigos 1xx: Informativo

100 continuam: Visto tipicamente com respeito ao protocolo ICAP. Esta é uma resposta informativa que nos deixe o cliente saber que pode continuar a enviar dados. Com respeito aos serviços ICAP (tais como a exploração do vírus), o server pode somente querer ver uma primeira quantidade x de bytes. Quando é feito que faz a varredura do primeiro grupo de bytes e não detectou um vírus, enviará uns 100 continua a deixar o cliente saber para enviar o resto do objeto.

códigos 2xx: Bem sucedido

APROVAÇÃO 200: O código o mais comum da resposta. Isto significa que o pedido é bem sucedido sem problemas.

códigos 3xx: Reorientação

302 encontrado: Esta é uma reorientação provisória. O cliente é instruído fazer um pedido novo para o objeto especificado no lugar: encabeçamento.

304 não alterado: Isto é em resposta a um GIMS (If-modified-since GET). Este é literalmente um padrão HTTP GET que inclua o If-modified-since do encabeçamento: <date>. Este encabeçamento diz ao server que o cliente tem uma cópia do objeto solicitado nele é cache local e incluída é a data onde o objeto foi buscado. Se o objeto foi alterado desde a aquela data, o server responderá com uma APROVAÇÃO 200 e uma cópia atualizada do objeto. Se o objeto não mudou desde que a data buscada, o server enviará para trás uma resposta 304 não alterada.

307 provisório reoriente: Para todos os efeitos, tem o mesmo significado que os 302. Se uns detalhes mais adicionais são descobertos, este artigo pode ser atualizado.

códigos 4xx: Erro de cliente

Pedido 400 ruim: Isto significa que a algo no pedido do HTTP não é seguinte sintaxe correta. As causas possíveis podiam ser devido aos encabeçamentos múltiplos que estão na mesma linha, espaços em um encabeçamento, nenhum HTTP/1.1 no URI, tão adiante. O RFC 2616 deve ser provido para a sintaxe adequada.

401 desautorizado: O objeto pedido exige a autenticação a fim ser alcançado. Os 401 é usado para a autenticação a um servidor de Web do destino. Ao usar a ferramenta de segurança da Web de Cisco (WSA) no modo transparente, uns 401 está enviado para trás ao cliente quando a autenticação é permitida no proxy. Isto é porque o dispositivo é falsificação próprio como se era os OC (server satisfeito da origem).

Os métodos de autenticação disponíveis são especificados em uma WWW-autenticação: Encabeçamento de resposta HTTP. Isto dirá ao cliente mesmo se este server está pedindo o NTLM, básico, ou outro método de autenticação.

403 proibido: O cliente é negado de alcançar o objeto solicitado. Há muitas causas para porque um server pode negar o acesso a um objeto. Tipicamente, o server incluirá alguma meio descrição da causa dentro dos dados HTTP (resposta HTML).

404 não encontrado: O objeto solicitado não existe no server.

Autenticação de proxy 407 exigida: Este é o mesmo que uns 401, salvo que é especificamente para a autenticação a um proxy, não os OC. Isto é enviado somente se o pedido foi enviado explicitamente ao proxy. Uns 407 não podem ser enviados a um cliente ao usar WSA como o proxy transparente, como o cliente não sabem que o proxy existe. Se este é o caso, o cliente muito provavelmente FIN ou RST o soquete TCP.

Em vez da utilização WWW-autentique: encabeçamentos para especificar que métodos de autenticação estão disponíveis, a proxy-autenticação: o encabeçamento é usado.

códigos 5xx: Erro do servidor

Erro de servidor interno 500: Falha do Servidor genérico

Gateway do mau 502: Você verá tipicamente este ao usar o WSA como um proxy, onde o gateway esteja respondendo incorretamente.

Serviço 503 não disponível: Isto é enviado tipicamente quando os OC estão estando sobre impedido. Tentar o pedido outra vez mais tarde deve ser bem sucedida.

Intervalo de 504 gateways: Uns 504 serão enviados se WSA não recebeu uma resposta de seu gateway.