Determine o final de uma solicitação HTTP malformada (incorreta)

Question

Determine o final de uma solicitação HTTP malformada (incorreta)

#1 resposta do (0 votos)
#2 resposta do (0 votos)

1

Estou implementando um servidor HTTP e me pergunto, se existe uma maneira definida de quando um servidor determinaria uma solicitação incorreta como finalizada

retorna o status 400 correspondente e
aceite os dados a seguir como nova solicitação, iniciando uma nova tentativa de análise.

A única idéia que me vem à mente seria muito ambígua: procurar os próximos dados da linha de solicitação recebidos e iniciar uma nova tentativa de análise a partir daí. No entanto, isso é, como dito, uma abordagem muito ambígua, uma vez que os dados de uma solicitação incorreta podem, é claro, conter os dados de 'linha de solicitação', sem que, na verdade, se pretenda que seja uma nova solicitação separada.

A mesma questão surge quando pensamos na análise de resposta do lado do cliente de respostas malformadas, de modo que levar em consideração este caso seria apreciado.

http parsing bad-request

por Reizo 07.05.2018 / 14:21

2 respostas

0

O cabeçalho termina com \r\n\r\n . Você simplesmente analisa cada entrada que precisa ler e as divide em argumento, strtok? ou strstr, ou manualmente.

Se você fala mais sobre a linha GET;

The HTTP protocol does not place any a priori limit on the length of
a URI. Servers MUST be able to handle the URI of any resource they
serve, and SHOULD be able to handle URIs of unbounded length if they
provide GET-based forms that could generate such URIs. A server
SHOULD return 414 (Request-URI Too Long) status if a URI is longer
than the server can handle (see section 10.4.15).
  Note: Servers ought to be cautious about depending on URI lengths
  above 255 bytes, because some older client or proxy
  implementations might not properly support these lengths.

Por favor, consulte o RFC 2616 para fazer com que seu servidor web reaja de acordo com o padrão.

nb, Certifique-se de que você está pronto para usar o atributo chunk também depois, se você quiser suportar HTTP1.0 +, senão seu servidor estará no padrão HTTP0.9.

por 07.05.2018 / 14:40

Tags http parsing bad-request

Quais caracteres / valores têm permissão para usar no DNS? É possível normalizar o URL “double-dots” usando nginx?

score 0 · Accepted Answer

Após algumas considerações, ficou claro que não há uma maneira universal aplicável para determinar o final de uma mensagem malformada, já que as mensagens sempre contêm alguns bits de informação autoexplicativos (por exemplo, o campo de cabeçalho Content-Length ) que permite ao destinatário para realmente entender a mensagem. Se, por exemplo, uma resposta ficaria assim:

HTTP/1.1 200 OK
Content-Length: [ consider correct content length here ]
Content-Type: text/html
<html>
    <head>
        <title>Title</title>
    </head>
    <body>
HTTP OK status messages look like this:
HTTP/1.1 200 OK
    </body>
</html>

O analisador do cliente provavelmente falharia no primeiro < , já que esperaria outro nome de campo de cabeçalho (devido à quebra única de linha após Content-Type -header) que não permite < . Além disso, ele deve (provavelmente) não "pesquisar" por outra resposta HTTP válida nos dados a seguir, pois ela pode receber corpos de mensagem como o fornecido, onde diz HTTP/1.1 200 OK , que não deve ser uma nova resposta. .

Assim, a melhor reação a uma mensagem http malformada parece estar fechando a conexão, já que qualquer outra tentativa de interpretar os dados a seguir recebidos é inevitavelmente ambígua.

No entanto, este não é o AFAIK especificado em RFC. Talvez porque o RFC seja mais sobre a definição de padrões e menos sobre como lidar com comportamentos não padronizados.