Por que o Wireshark não reconhece essa resposta HTTP?

Question

Eu tenho um script CGI trivial que gera um conteúdo de texto simples. Está escrito em Perl e usando CGI module e especifica apenas os cabeçalhos mais básicos:

print $q->header(
    -type               => 'text/plain',
    -Content_length     => $length,
);
print $stuff;

Não há problemas aparentes com a funcionalidade - nem o Agente do Usuário nem o servidor reclamam um pouco, mas estou confuso sobre o fato de o Wireshark não reconhecer a resposta HTTP como HTTP - está marcado como TCP.

Aqui está a solicitação e a resposta, conforme mostrado na caixa de diálogo "Seguir o fluxo de TCP":

GET /cgi-bin/memfile/memfile.pl?mbytes=1 HTTP/1.1
Host: 10.0.0.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20100101 Firefox/11.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: cs,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive

HTTP/1.1 200 OK
Date: Thu, 05 Apr 2012 18:52:23 GMT
Server: Apache/2.2.15 (Win32) mod_ssl/2.2.15 OpenSSL/0.9.8m
Content-length: 1048616
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/plain; charset=ISO-8859-1

XXXXXXXX...

E aqui está a visão geral do pacote)

No.     Time        Source      srcp   Destination  dstp    Protocol    Info                                tcp.stream  abstime
5       0.112749    10.0.0.1    80     10.0.0.2     48072   TCP         [TCP segment of a reassembled PDU]  0           20:52:23.228063

Frame 5: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits)
Ethernet II, Src: 00:12:34:56:78:9a, Dst: 00:12:34:56:78:9b
Internet Protocol Version 4, Src: 10.0.0.1 (10.0.0.1), Dst: 10.0.0.2 (10.0.0.2)
Transmission Control Protocol, Src Port: http (80), Dst Port: 48072 (48072), Seq: 1, Ack: 330, Len: 1460

Agora, quando eu abrir o fluxo no Wireshark:

• os três primeiros pacotes são o handshake TCP usual
• quarto pacote a solicitação GET mostrada como HTTP com isso no campo "Info" GET /cgi-bin/memfile/memfile.pl , como espero
• quinto pacote contém a resposta, mas não está marcado como uma resposta HTTP. Eu esperaria que o campo Info fosse algo como "HTTP 200 OK", mas há apenas um "[segmento TCP de uma PDU remontada] genérica". O verdadeiro inconveniente é que este pacote não é capturado pelo filtro "http.response"

Alguém pode explicar porque o Wireshark não reconhece a natureza HTTP do quinto pacote? Há algo de errado com a resposta?

    

Answer 1

Eu mesmo tive o mesmo problema e encontrei a resposta na Wireshark Q & A:

You can make Wireshark show the HTTP response straight away by disabling the "Allow Subdissector to reassemble TCP streams" in the TCP protocol preferences" (you need to restart Wireshark after disabling the option).

    

Answer 2

Para explicar o porquê da resposta de Zorel ...

Quando a preferência do WireShark é remontar mensagens com múltiplos pacotes, ele não sabe que as mensagens são HTTP até que tenha visto tudo e a remontagem esteja completa.

Assim, os pacotes são primeiro reportados como TCP (o que eles são) e após a remontagem relatada novamente como HTTP.

Na linha remontada, você verá algo como:

Frame 10: ...
...
[3 Reassembled TCP segments (2496 bytes): #8(316), #9(1324), #10(856)]
Hypertext Transfer Protocol
...

Que indica quais números de registro e quantos bytes cada um forneceu para a entrada reagrupada.

No seu caso, a resposta é 1048616 bytes, então serão MUITOS pacotes antes que saiba que é HTTP. Sua entrada indicada diz:

[TCP segment of a reassembled PDU]

Essa é outra indicação de que a WireShark está adiando a exibição final dessa mensagem.