Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-bugs: [Wireshark-bugs] [Bug 6043] New: Malformed http field data improperly interprete

Date: Mon, 20 Jun 2011 08:05:07 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6043

           Summary: Malformed http field data improperly interpreted
           Product: Wireshark
           Version: 1.6.0
          Platform: x86
        OS/Version: Windows 7
            Status: NEW
          Severity: Minor
          Priority: Low
         Component: Wireshark
        AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
        ReportedBy: kcullimo@xxxxxxxxxxxxxxx


Created an attachment (id=6524)
 --> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=6524)
single packet containing two HTTP subtrees, one undecoded

Build Information:
C:\>wireshark -v

C:\>

wireshark 1.6.0rc2 (SVN Rev 37523 from /trunk-1.6)

Copyright 1998-2011 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 (32-bit) with GTK+ 2.22.1, with GLib 2.26.1, with WinPcap (version
unknown), with libz 1.2.5, without POSIX capabilities, without libpcre, with
SMI
0.4.8, with c-ares 1.7.1, with Lua 5.1, without Python, with GnuTLS 2.10.3,
with
Gcrypt 1.4.6, with MIT Kerberos, with GeoIP, with PortAudio V19-devel (built
Jun
 2 2011), with AirPcap.

Running on 32-bit Windows 7, build 7600, with WinPcap version 4.1.2 (packet.dll
version 4.1.0.2001), based on libpcap version 1.0 branch 1_0_rel0b (20091008),
GnuTLS 2.10.3, Gcrypt 1.4.6, with AirPcap 4.1.1 build 1838.

Built using Microsoft Visual C++ 9.0 build 21022

--
Packet Details Pane:

2 Hypertext Transfer Protocol trees.

1st one contains subtrees & associated decode information.

2nd one contains the last field of the scheme header, interpreted as raw data.

Presumably, this may well be due to how the ascii string Connection: Keep-Alive
was presented across the atmosphere. 

One would expect to encounter the following list of bytes:

(frame byte offset: 546 [decimal])

43:6f:6e:6e:65:63:74:69:6f:6e:3a:20:4b:65:65:70:2d:41:6c:69:76:65

instead, the captured/saved packet contains the following:

43:6f:1d:6e:65:63:74:69:6f:6e:3a:20:4b:65:65:70:2d:41:6c:69:76:65

Clearly, the 3rd hexit/hexit-pair, starting with a "1", falls well outside the
nearly-contiguous range of alphabetic characters, and gets interpreted as a "."
(an all-too-common fate).

During the last Sharkfest's Q&A session, a modest sense of agreement appeared
to emerge that the code could be altered to accommodate these irregularities.
Let me know if the surrounding packets would facilitate a fix (it's the only
packet from that particular stream I was able to capture).

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.