Problem with http dissector on 204 with Content-type

Question

Hello,

I'm facing a problem I don't understand and I hope that someone here can help me.

I managed to reduce it to a simple pcap (available here: http://dl.free.fr/eheNlphr1) which is only a few KB.

If I run:

tshark -r weird-204.pcap -T fields -e frame.number -e frame.time -e ip.src -e http.response.code -e http.time

I get this output:

1   Nov  9, 2016 17:45:55.453409000 CET 176.31.224.85       
2   Nov  9, 2016 17:45:55.490626000 CET 46.228.164.12       
3   Nov  9, 2016 17:45:55.490644000 CET 176.31.224.85       
4   Nov  9, 2016 17:45:56.633395000 CET 176.31.224.85       
5   Nov  9, 2016 17:45:56.653943000 CET 46.228.164.12       
6   Nov  9, 2016 17:45:56.653959000 CET 176.31.224.85       
7   Nov  9, 2016 17:46:11.330837000 CET 176.31.224.85       
8   Nov  9, 2016 17:46:11.350015000 CET 46.228.164.12   204,204 14.716620000
9   Nov  9, 2016 17:46:11.350034000 CET 176.31.224.85

What I don't understand is that packet 8 seems to have 2 204 responses. If you look carefully at the packets, you will see that: packet 1 is the HTTP request, packet 2 is an HTTP response 204 (the first one), packet 3 is an ack for packet 2, packet 4 is the second HTTP request, etc.

I was expecting to have packet 2 dissected as an HTTP response with status 204 but it is not.

At this point, I suspect this is linked to the presence of Content-type (which, admittedly is weird for a 204 but not forbidden). If it is the reason, is there any way to change the behavior and have the packet 2 dissected as an HTTP response.

Apologies if my terminology around dissection and packets/frames/PDU is not correct.

And thanks to any help anyone could provide.

Antoine.

Accepted Answer

To me, the problem is not so much the presence of the Content-Type header in a 204 response as the absence of any actual content in a PDU bearing this header.

If I get right what happens, the absence of contents where it is expected due to presence of Content-Type header somehow makes the HTTP dissector return "not enough data" when it is offered frame 2, causing the TCP dissector to continue reassembly and offer the contents of frame 2 to the HTTP dissector once more, concatenated with the contents of frame 5, with the same result (HTTP dissector doesn't find any content even here so it returns "not enough data" again).

Only the zero size of the TCP payload which comes in frame 8 somehow makes the HTTP dissector process both the previously received PDUs properly, probably because it analyses them into deeper detail than in the previous passes, and render them as two distinct PDUs in a single reassembled segment.

I recommend you to file a bug as the HTTP dissector is clearly able to handle the (weird!) data properly, except that it is "lazy" to do that already during the initial "fast scan" phase.

If that may help you continue analysis of a particular scenario, unticking the (ticked by default) HTTP dissector preference Reassemble HTTP bodies spanning multiple TCP segments will cause these 204s with Content-Type header to be dissected properly, but it will break analysis of 200s with bodies which exceed the size of a single TCP segment. Closing Wireshark saves the setting into the preferences file in the profile which tshark uses as well, or you may override the default setting only for a single run of tshark, i.e. without saving it to the preferences file, by adding -o "http.desegment_body:FALSE" to your command line.