Sorry,
I did not answer to this: (I'm lazy :-)
> the Requests are divided into address and name, while the Responses
> shows only the addresses, which makes the understanding more difficult
> than it could be.
There's no Host: header in the response so I do not know which virtual
host is the response coming from.
I considered correlating http requests and responses but with this
packet-http.c its a lost battle to begin with.
Taking into account that this dissector does not do a good job at all
for pipelined requests when the client or server don't PSH each
message (1). Implementing a request-response matching would become a
nightmare as other than the order in which they come in the stream
there's little in http to indicate me what response is for which
request. Think in out of order tcp packets.
I have an embryonic http-like dissector whose fully heuristic
disssection does a much better job handling pipelined messages but it
lacks way too many features that the current one has to even think
replacing it. Not to mention that right now it gets fooled if a valid
http header is contained in the body of a message, it doesn't yet
handle fragmentation of headers which would put me back in the current
state of things. I left it aside some time ago, one day I might go
back to it.
(1) does not dissect mesages starting in the the middle of a packet
when the packet starts with the last fragment of a body.
