On Sat, Jun 07, 2003 at 01:48:22PM -0500, Gilbert Ramirez wrote:
> I've been needing the ability to filter on the HTTP method in HTTP
> packets; e.g., I want to see all HTTP POST's. Attached is a patch which
> adds the http.method field. Instead of just checking this in I'm asking
> for a review since 1) I haven't checked in any ethereal code in a looong
> time, and 2) maybe it's wrong.
At least from a quick look, it seems sane (and presumably you've tried
it on HTTP captures so I don't have to).
It does raise one question, though - there are several protocols of that
sort (descendants of FTP - RFC 354 appears to be the first RFC
with "transfer protocol" in its name describing an ASCII-based protocol
with requests containing a command name and replies containing a 3-digit
response code), but not all of the dissectors handle them the same:
the FTP and SMTP dissectors put the request command and
arguments, and reply code and arguments, into the protocol tree
as separate items, but don't put the full request or reply
line in as a separate item;
the HTTP, NNTP, and RTSP dissectors currently put the request
and reply line into the protocol tree, but don't put the request
method or reply code, or their args, in;
the SIP dissector puts the request and reply line in *and* puts
the request method and reply code in as the next item, at the
same protocol tree level as the request or reply line.
I suspect the right answer is to put both the full request/reply line,
and the relevant fields in that line (the version string, for protocols
where one of the fields is a version string, might also be useful, e.g.
to look for HTTP/1.0 or HTTP/1.1), into the protocol tree.
However, I'm not sure whether the right thing is to put the fields in at
the same protocol tree level as the request/reply line, or to give the
request/reply line a subtree and put those fields into that subtree, so
that the top-level display shows the lines of the request or reply.
