This only affects PDUs that spans multiple tcp segments.
This can not be solved in the HTTP dissector but requires that the TCP dissector and the TCP reassembly code is enhanced to provide an api such as "reassemble tcp data from this segment and all the way until a RST or a FIN"
TCP reassembly does not currently support this and only support the api
"reassemble TCP until sequence number x"
So, the solution is :
1, enhance the tcp reassembly code to provide the new semantic : reassemble until RST or FIN (most of the work)
2, change the http dissector to call this new reassembly api when content-length is missing instead of the normal one (a few lines of code at most)
On 9/8/06,
Bryant Eastham <beastham@xxxxxxxxxxx> wrote:
It appears that HTTP requests/responses that are not chunked and do not
include a Content-Length cannot be decoded correctly. The following
comment appears in the code:
* If no content length was supplied (or if a bad content length
* was supplied), the amount of data to be processed is the
amount
* of data remaining in the frame.
*
* If there was no Content-Length entity header, we should
* accumulate all data until the end of the connection.
* That'd require that the TCP dissector call subdissectors
* for all frames with FIN, even if they contain no data,
* which would require subdissectors to deal intelligently
* with empty segments.
My understanding is that the logic to "accumulate all data until the end
of the connection" is not currently possible (or at least not currently
implemented).
I now have the following problem. It is common for our implementation to
dump the headers in one segment and then dump the data in the next, with
no Content-Length. Yes, we should set the Content-Length and the problem
goes away, but the engineer didn't, and shouldn't really have to.
So:
1. The packet with the headers is not passed to my subdissector because
there is no data. The 'if' statement at line 901 of packet-http.c sees
to that.
2. The packet without my headers is passed to my subdissector, but
without the headers I can't tell that it is mine.
A solution would be to create a conversation and attach the header
information to it when I notice that it is my protocol, but that doesn't
work because of #1 - I don't get a chance to create the conversation.
The solution appears to either be to implement the logic described in
the comments - far beyond my meager knowledge - or to pass packets with
no data (but with headers) to subdissectors.
Does this make sense, or am I missing something? Would it be acceptable
to pass zero-data-length packets to subdissectors?
Should I take this offline with the primary HTTP maintainer? And is that
Guy Harris?
Thanks,
Bryant Eastham
Chief Architect
Panasonic Electric Works Laboratory of America, Inc.
Salt Lake City Lab
4525 South Wasatch Blvd., Suite 100, Salt Lake City, Utah 84124
Phone : 801.993.7124 Email: beastham@xxxxxxxxxxx
Fax: 801.993.7260 Web:
http://slc.mew.com <http://slc.mew.com/>
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev
