Comment # 22
on bug 12855
from Erik Hjelmvik
(In reply to Michael Mann from comment #21)
> (In reply to Erik Hjelmvik from comment #20)
> > The wanted behaviour in the follow TCP stream would be to see only one HTTP
> > response, not two or three. The response shown in the follow TCP stream
> > should contain a 1633 byte valid HTML file.
>
> Current state of the patch duplicates 2.0 behavior which still has the
> response as 1712 bytes (but the response is only shown once)
If WS now behaves like 2.0, then that's great!
The desired behaviour would be for the follow TCP to interpret the stream data
the same way as the TCP stack at the receiving end, which was working in
version 2.0.x and earlier.
Here's how tshark 2.0.2 nicely performs a follow TCP stream of
145-reordered-filtered3.pcap:
tshark -r 145-reordered-filtered3.pcap -z follow,tcp,ascii,0
1 0.000000 0.0.0.0 -> 113.6.227.240 HTTP 982 GET
/js/6v/biz/common/store-proxy/store-proxy2.html?iframe_delete=true HTTP/1.1
2 0.551363 113.6.227.240 -> 0.0.0.0 HTTP 1440 HTTP/1.1 200 OK
3 0.547699 113.6.227.240 -> 0.0.0.0 TCP 596 [TCP Retransmission] 80 →
64867 [PSH, ACK] Seq=1 Ack=943 Win=38 Len=556
4 0.551379 113.6.227.240 -> 0.0.0.0 TCP 358 [TCP segment of a
reassembled PDU]
5 0.697782 113.6.227.240 -> 0.0.0.0 TCP 46 [TCP Retransmission] 80 →
64867 [PSH, ACK] Seq=555 Ack=943 Win=38 Len=1
===================================================================
Follow: tcp,ascii
Filter: tcp.stream eq 0
Node 0: 0.0.0.0:64867
Node 1: 113.6.227.240:80
942
GET /js/6v/biz/common/store-proxy/store-proxy2.html?iframe_delete=true HTTP/1.1
[...HTTP_HEADERS---]
1400
HTTP/1.1 200 OK
Content-Length: 1633
Cache-Control: no-cache
Connection: close
[...HTML...]
318
[...HTML...]
===================================================================
Any reassembly different than this should be considered a bug. I.e. Frames 3
and 5 should not be part of the reassembled data.
You are receiving this mail because:
- You are watching all bug changes.