https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3242
Summary: Dynamic header fields for HTTP
Product: Wireshark
Version: SVN
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: Enhancement
Priority: Low
Component: Wireshark
AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
ReportedBy: sarkar.abhik@xxxxxxxxx
Abhik Sarkar <sarkar.abhik@xxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #2729| |review_for_checkin?
Flag| |
Created an attachment (id=2729)
--> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=2729)
Patch for the enhancement. It has been checked using checkhfs.pl and
checkAPIs.pl and has also been fuzz tested using a capture which has MMSE
encapsulated in HTTP.
Build Information:
F:\wireshark-src\wireshark-gtk2>tshark -v
TShark 1.1.3-AS (SVN Rev 27365)
Copyright 1998-2009 Gerald Combs <gerald@xxxxxxxxxxxxx> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled with GLib 2.18.4, with WinPcap (version unknown), with libz 1.2.3,
without POSIX capabilities, with libpcre 7.0, with SMI 0.4.8, with c-ares
1.6.0,
with Lua 5.1, with GnuTLS 2.6.3, with Gcrypt 1.4.3, with MIT Kerberos, with
GeoIP.
Running on Windows XP Service Pack 2, build 2600, with WinPcap version 4.0.2
(packet.dll version 4.0.0.1040), based on libpcap version 0.9.5, GnuTLS 2.6.3,
Gcrypt 1.4.3.
Built using Microsoft Visual C++ 9.0 build 30729
F:\wireshark-src\wireshark-gtk2>
--
Currently when the HTTP dissector comes ac across a message-header that is
unrecognized, it adds the header entire line as a text item. This makes it
impossible for a user to filter on that header or extract the information from
that header using tshark.
A user (Appusamy Dinesh) recently brought up this requirement on the
Wireshark-users list, and I thought it was a valid requirement.
With the attached patch this is now possible. When the HTTP dissector
encounters a header which is not recognized, it will register a new header
field with the abbreviation "http.header.<header name>". The FTYPE is always
FT_STRING.
It works well with Wireshark. However, with tshark the behaviour is bit
inconsistent, and perhaps someone can check out why... here's the relevant
output.
C:\Documents and
Settings\sarkara\Desktop>f:\wireshark-src\wireshark-gtk2\tshark
-r mm1_mm1.cap -d "tcp.port==10021,http" -T fields -e "http.header.sgsn" -R
"ht
tp.user_agent contains SAMSUNG"
60302
60302
60302
60302
60302
60302
60302
60302
60302
60302
60302
60302
60302
60302
60302
60302
C:\Documents and
Settings\sarkara\Desktop>f:\wireshark-src\wireshark-gtk2\tshark
-r mm1_mm1.cap -d "tcp.port==10021,http" -T fields -e "http.header.sgsn" -R
"ht
tp.header.sgsn contains 6030"
tshark: Neither "http.header.sgsn" nor "6030" are field or protocol names.
C:\Documents and Settings\sarkara\Desktop>
Also, should this patch be accepted, I would appreciate that the person
committing the patch check that the logically correct memory allocation
functions have been used.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.