Compartilhar via

Solução de problemas de erros HTTP 400 no IIS

  • Artigo

por Mike Laing

Ferramentas usadas nesta solução de problemas:

  • Monitor de Rede
  • Log de erros HTTP

Esse material é fornecido somente para fins informativos. A Microsoft não oferece nenhuma garantia, expressa ou implícita.

Visão geral

Depois de enviar uma solicitação HTTP para um servidor IIS, um cliente HTTP (como o Internet Explorer) pode exibir o seguinte tipo de mensagem de erro:

HTTP 400A página da Web não pode ser encontrada.

Causas mais prováveis:

  • Pode haver um erro de digitação no endereço.
  • Se você clicou em um link, ele pode estar desatualizado.

O que você pode tentar:

  • Digite novamente o endereço.
  • Voltar à página anterior.
  • Vá para o Bing e procure as informações desejadas.

Se o cliente HTTP for Internet Explorer e a opção Mostrar Mensagens de Erro HTTP Amigável estiver desativada, o erro poderá ser semelhante ao seguinte:

Solicitação incorreta

Nesses cenários, o IIS rejeitou a solicitação HTTP do cliente porque a solicitação não cumpriu as regras de análise HTTP do servidor ou excedeu os limites de tempo ou falhou em alguma outra regra à qual o IIS ou HTTP.sys exigir solicitações de entrada para aderir. O IIS envia o status HTTP 400 – Solicitação Incorreta de volta para o cliente e, em seguida, encerra a conexão TCP.

Solução de problemas de métodos

Ao solucionar problemas de uma condição HTTP 400, é importante lembrar que o problema subjacente é que o cliente enviou uma solicitação ao IIS que quebra uma ou mais regras que HTTP.sys está impondo. Com isso em mente, você vai querer ver exatamente o que o cliente está enviando para o IIS; para fazer isso, capture um rastreamento de rede do cliente enviando a solicitação incorreta. Você pode analisar o rastreamento para ver os dados brutos que o cliente envia ao IIS e ver os dados de resposta brutos que o IIS envia de volta para o cliente. Você também pode usar uma ferramenta de detecção HTTP chamada Fiddler; essa é uma ótima ferramenta, pois permite que você veja os cabeçalhos HTTP mesmo que o cliente e o servidor estejam se comunicando por SSL.

O próximo item de dados que você deseja usar é o C:\Windows\System32\LogFiles\HTTPERR\httperr.log arquivo. A partir do IIS 6.0, o componente HTTP.sys lida com solicitações HTTP de entrada antes de serem passadas para o IIS e é o componente responsável por bloquear solicitações que não atendem aos requisitos do IIS. Quando HTTP.sys bloquear a solicitação, ela registrará informações em seu arquivo httperr.log sobre a solicitação incorreta e por que ela foi bloqueada.

OBSERVAÇÃO: Para obter mais informações sobre o log de erros da API HTTP que HTTP.sys fornece, consulte o seguinte artigo:

Tecnicamente, é possível, embora não muito provável, que um cliente receba uma resposta HTTP 400 que não tenha uma entrada de log associada no httperr.log. Isso pode acontecer se um filtro ou extensão ISAPI ou um módulo HTTP no IIS definir o status 400, nesse caso, você poderá examinar o log do IIS para obter mais informações. Isso também pode acontecer se uma entidade entre o cliente e o servidor, como um servidor proxy ou outro dispositivo de rede, interceptar uma resposta do IIS e substituí-la com seu próprio status 400 e/ou erro "Solicitação Incorreta".

Cenário de exemplo

A seguir está um exemplo de um cenário HTTP 400, em que um cliente envia uma solicitação incorreta para o IIS e o servidor envia de volta uma mensagem HTTP 400 – Solicitação Incorreta.

Quando o cliente envia sua solicitação, o erro do navegador que ele recebe é semelhante ao seguinte:

Solicitação inválida (campo cabeçalho muito longo)

Capturando um rastreamento de rede da solicitação e da resposta, vemos a seguinte solicitação/resposta bruta:

SOLICITAÇÃO:

HTTP: GET Request from Client
HTTP: Request Method =GET
HTTP: Uniform Resource Identifier =/1234567890123456789012345678901234567890/time.asp
HTTP: Protocol Version =HTTP/1.1
HTTP: Accept-Language =en-us
HTTP: UA-cpu =x86
HTTP: Accept-Encoding =gzip, deflate
HTTP: Host =iisserver
HTTP: Connection =Keep-Alive
HTTP: Data: Number of data bytes remaining = 14 (0x000E)

RESPOSTA:

HTTP: Response to Client; HTTP/1.1; Status Code = 400 - Bad Request
HTTP: Protocol Version =HTTP/1.1
HTTP: Status Code = Bad Request
HTTP: Reason =Bad Request
HTTP: Content-Type =text/html
HTTP: Date =Wed, 14 Nov 2012 20:36:36 GMT
HTTP: Connection =close
HTTP: Content-Length =44
HTTP: Data: Number of data bytes remaining = 63 (0x003F)

Você observará que os cabeçalhos de resposta não nos dizem tanto quanto a mensagem de erro no navegador. No entanto, se examinarmos os dados brutos no corpo da resposta, veremos mais:

00000030                                           48 54               HT
00000040 54 50 2F 31 2E 31 20 34 30 30 20 42 61 64 20 52 TP/1.1.400.Bad.R
00000050 65 71 75 65 73 74 0D 0A 43 6F 6E 74 65 6E 74 2D equest..Content-
00000060 54 79 70 65 3A 20 74 65 78 74 2F 68 74 6D 6C 0D Type:.text/html.
00000070 0A 44 61 74 65 3A 20 57 65 64 2C 20 32 38 20 4A .Date:.Wed,.28.J
00000080 61 6E 20 32 30 30 39 20 32 30 3A 33 36 3A 33 36 an.2009.20:36:36
00000090 20 47 4D 54 0D 0A 43 6F 6E 6E 65 63 74 69 6F 6E .GMT..Connection
000000A0 3A 20 63 6C 6F 73 65 0D 0A 43 6F 6E 74 65 6E 74 :.close..Content
000000B0 2D 4C 65 6E 67 74 68 3A 20 34 34 0D 0A 0D 0A 3C -Length:.44....<
000000C0 68 31 3E 42 61 64 20 52 65 71 75 65 73 74 20 28 h1>Bad.Request.(
000000D0 48 65 61 64 65 72 20 46 69 65 6C 64 20 54 6F 6F Header.Field.Too
000000E0 20 4C 6F 6E 67 29 3C 2F 68 31 3E 01 02 03 04 05 .Long).....
000000F0 05 06 0E 94 63 D6 68 37 1B 8C 16 FE 3F D5       ....c.h7....?.

Você pode ver que o texto da mensagem de erro exibido no navegador também pode ser exibido nos dados de resposta brutos no rastreamento de rede.

A próxima etapa é examinar o arquivo httperr.log no C:\Windows\System32\LogFiles\HTTPERR diretório para a entrada que corresponde à solicitação incorreta:

#Software: Microsoft HTTP API 1.0
#Version: 1.0
#Date: 2012-11-14 20:35:02
#Fields: date time cs-version cs-method cs-uri sc-status s-reason 
2012-11-14 20:36:36 HTTP/1.1 GET /1234567890/time.asp 400 FieldLength

Nesse cenário, o campo Motivo no arquivo httperr.log nos fornece as informações exatas necessárias para diagnosticar o problema. Vemos aqui que HTTP.sys FieldLength registrado como a frase razão para a falha dessa solicitação. Depois que soubermos a frase de motivo, podemos usar o log de erros no artigo da API HTTP mencionado acima para obter sua descrição:

FieldLength: A field length limit was exceeded.

Portanto, neste ponto, sabemos pela mensagem de erro do navegador e o log de erros da API HTTP que a solicitação continha dados em um de seus cabeçalhos HTTP que excediam os limites de comprimento permitidos. Para este exemplo, o cabeçalho HTTP: Uniform Resource Identifier é propositalmente longo: /1234567890123456789012345678901234567890/time.asp.

O estágio final da solução de problemas deste exemplo é usar o seguinte artigo para ver as chaves do registro HTTP.sys e as configurações padrão do IIS:

Como sabemos que a frase e o erro do motivo estão sugerindo um comprimento de campo de cabeçalho que excede limites, podemos restringir nossa pesquisa no KB820129 como tal. O principal candidato aqui é:

MaxFieldLength: define um limite superior para cada cabeçalho. Consulte MaxRequestBytes. Esse limite se traduz em aproximadamente 32 mil caracteres para uma URL.

Para reproduzir esse erro para este exemplo, a chave do registro MaxFieldLength foi definida com um valor 2. Como a URL solicitada tinha um campo de cabeçalho HTTP: Uniform Resource Identifier com mais de 2 caracteres, a solicitação foi bloqueada com a frase de motivo FieldLength.

Outro cenário HTTP 400 comum é aquele em que o usuário que está fazendo a solicitação HTTP é membro de um grande número de grupos do Active Directory e o site é configurado para autenticação Kerberos do usuário. Quando isso ocorrer, uma mensagem de erro semelhante à seguinte será exibida para o usuário:

Solicitação inválida (cabeçalho de solicitação muito longo)

Nesse cenário, o token de autenticação incluído como parte da solicitação HTTP do cliente é muito grande e excede os limites de tamanho que http.sys está impondo. Esse problema é discutido em detalhes, juntamente com a solução, no seguinte artigo da Base de Dados de Conhecimento:

Outros recursos