Comment # 4
on bug 9381
from Deepak Nagaraj
It looks like the change works if the HTTP headers and the extra data all come
in the same packet. For example, on a large capture file, I found these
mismatches:
Errors (23267)
=============
Frequency Group Protocol Summary
23260 Checksum IPv4 Bad checksum
3 Malformed HTTP Actual length 663 greater than
Content-Length header value 358, using header value
2 Malformed HTTP Actual length 470 greater than
Content-Length header value 160, using header value
2 Malformed UASIP Malformed Packet (Exception
occurred)
In each of the 5 error cases, the entire HTTP response was in one packet. I
will try to simulate this and update a trace file.
So the check fails if there is extra data and that is coming in a separate
packet.
The printfs showed that the variables were as expected:
reported_datalen: 663, content_length: 358
Pascal, I did not understand this statement: "reports the remaining length for
the reassembled segment, not from the original packet". I will check the code
you mentioned. But note the above "partially working" case.
Evan, I am OK with truncating reassembly to advertised "Content Length" - this
is the current approach taken by packet-http.c. I only want a warning in the
Expert-Info that this happened on response starting at packet N. As you can
see above, it works with my patch (on 1.8.2), but only sometimes.
You are receiving this mail because:
- You are watching all bug changes.