I checked in some stuff to dissect HTTP (ports 80 and 8080); it attempts
to recognize the lines that appear in HTTP requests and replies, and
shows them, with non-printable characters escaped. (The routines to
recognize "lines" - which can end with LF, CR-LF, or CR - and to format
them with non-printable characters escaped are in "packet.c", and
potentially usable by other protocols, e.g. FTP, SMTP, etc..)
It reveals a problem with the current way of passing information to the
next dissector down, namely that if the dissector at level N knows that
its payload ends before the end of the frame (e.g., an Ethernet frame
that had to be padded to be at least 60 bytes), it doesn't tell the
dissector at level N+1.
The ideas I've been thinking about for handling "packets" that take more
than one frame (e.g., ONC RPC or NetBIOS-over-TCP requests and replies
that fit in more than one IP fragment over UDP or more than one TCP
segment), and handling more than one "packet" in a frame (e.g., ONC
RPC-over-TCP or NetBIOS-over-TCP requests packed two or more to a TCP
segment) would handle this as well, in that the level N decoder would
hand the level N+1 decoder a scatter/gather list, if you will, of raw
frame data (pointer+length), and possibly a total length as well.
