https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6438
--- Comment #3 from Stephen Fisher <steve@xxxxxxxxxxxxxxxxxx> 2011-10-07 10:21:23 MDT ---
I installed a trial of UltraEdit on Win7 and duplicated the issue you're
seeing. It happens whenever plain text shows up in the HTTP stream (such as
the headers) but not binary data. It also happens with a telnet session to a
Cisco router, so it's not specific to HTTP.
The Follow TCP Stream window uses follow_write_raw() or follow_print_text()
from gtk/follow_stream.c for the "printing" to the screen, which in this
respect are the same. Neither appends carriage returns or line feeds to do the
wrapping.
However, the telnet/HTTP data has each line terminated with a carriage return
and line feed, "\r\n", which is most likely causing this. When I paste the
information into UltraEdit (which starts with a single \r\n or 0d0a in hex),
and then save it, and then do a hexdump of the text file on a Unix machine, it
now has two \r\n combinations after each line, which is the problem: for each
\r\n combination, UltraEdit appears to be making it two.
When I paste it into notepad, the \r\n from Wireshark is ignored and, without
Word Wrap turned on, it becomes one long line.
My educated guess so far is that GTK, the GUI toolkit that Wireshark uses, is
putting the \r\n into the copy and paste buffer of Windows and some
applications, such as UltraEdit, are accepting it and others, such as Noteapd,
are ignoring it.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
