Sometimes I simply want to read the Content-Disposition parameters of file uploads. For example:
POST http://250kb.de/upload/ HTTP/1.1
Host: 250kb.de
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://250kb.de/
Cookie: PHPSESSID=o3rsceuoc9amk23i0j97aorsj2; __utma=177882470.523068217.1411082996.1411082996.1411082996.1; __utmb=177882470.2.10.1411082996; __utmc=177882470; __utmz=177882470.1411082996.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)
Connection: keep-alive
Content-Type: multipart/form-data; boundary=---------------------------1011289771747
Content-Length: 647
-----------------------------1011289771747
Content-Disposition: form-data; name="file_0"; filename="pixel.gif"
Content-Type: image/gif
GIF89a�����������!�����,�������D�;
-----------------------------1011289771747
Content-Disposition: form-data; name="scaling[0]"
no-scaling
-----------------------------1011289771747
Content-Disposition: form-data; name="duration"
forever
-----------------------------1011289771747
Content-Disposition: form-data; name="acceptTOS"
1
-----------------------------1011289771747
Content-Disposition: form-data; name="upload"
Hochladen
-----------------------------1011289771747--
14 Answers, 1 is accepted
For your scenario, you could write a custom inspector that shows the data you want, or you could use the HexView inspector, which is explicitly designed for the scenario of viewing requests and responses containing binary data. The HexView control offers very high performance even when viewing huge requests or responses.
Regards,
Eric Lawrence
Telerik
Check out the Telerik Platform - the only platform that combines a rich set of UI tools with powerful cloud services to develop web, hybrid and native mobile apps.

I'm not sure what "makes reading everything way too complicated" means. You can make HexView wider so that you can read more text on a single line. You can use the "Find String" context menu to search for the string form-data and you can hit F3 to navigate from one match to the next.
Regards,
Eric Lawrence
Telerik
Check out the Telerik Platform - the only platform that combines a rich set of UI tools with powerful cloud services to develop web, hybrid and native mobile apps.

Regards,
Eric Lawrence
Telerik
Check out the Telerik Platform - the only platform that combines a rich set of UI tools with powerful cloud services to develop web, hybrid and native mobile apps.

See here: https://github.com/henricj/Fiddler2-SmartViewer
It should be trivial to adapt it for use as a request inspector.
Note that filtering out the NULs characters before feeding the text to the UI seems to help.
It would be nice if Fiddler didn't choke on large binaries without needing external help.
As far as I can tell, your approach (which doesn't work properly for most web content, encoded in UTF-8) simply uses a TextBox instead of a RichTextBox for display. This may allow you to avoid performance problems that Microsoft introduced in the RichTextBox control. when it is asked to render non-textual content.
Filtering out null characters actually creates problems rather than resolving them, because a null character would otherwise be treated as "end of content"; by removing it, you force the textbox to attempt to continue to render the non-textual content.
Fundamentally, it remains the case that inspecting binary content as text is doomed to failure. The HexView should be used for binary content.
Regards,
Eric Lawrence
Telerik
Check out the Telerik Platform - the only platform that combines a rich set of UI tools with powerful cloud services to develop web, hybrid and native mobile apps.

Yes, most textual web content is encoded in UTF-8, but I would venture to suggest there is as least as much non-textual web content (from .jpegs to .zip files). And yes, trying to make sense of arbitrary binary content as text is doomed. It would be nice if feeding the Raw tab such data did not cause the UI to hang.
However, when I'm faced with unknown content that might be text, the raw tab is where I want to start (even .zip files have snippets of decipherable ASCII). A quick glance at the bottom of the pane distinguishes text from gunk (unlike the HexView). The headers are often important, so "Raw" should be perfect. If it has western text, then it is easy to decipher. If binary, one can still read the headers (unless some random NUL has stopped things up) and the rest is gunk, sometimes with some readable text blocks here and there. One can go over to the HexView to see the particulars of the binary content and see the very same Latin1 characters in HexView's third column but with the original line endings lost and irrelevant data in the other columns taking up most of the pane.
Random data (mis-)interpreted as UTF-8 or UTF-16 can get at every character the system can render, one can wind up with a text box containing both right-to-left and left-to-right text, every weird character one can think of (from symbols to runes), one winds up giving the text rendering engine and CPU quite the workout. Latin1 has less than 256 possible symbols and everything renders left-to-right. That is Western-centric, but protocol-related text usually is (e.g., HTTP headers and the "Content-Disposition: form-data;" stuff from above); such ASCIIish stuff encoded as UTF-8 is identical to the Latin1 encoding. If there is non-Western text, then one usually needs to get the encoding right to get anything other than mojibake. More fundamentally, there is already a TextView tab that is there for showing stuff known to be text (a box to force the encoding to an arbitrary entry in Encoding.GetEncodings() and a quick way to switch to a fixed with font would be great there).
Try playing http://devimages.apple.com/iphone/samples/bipbop/bipbopall.m3u8 with VLC while monitoring the traffic in Fiddler. It is not a live stream, so there are no playlist downloads interleaved between the media segments. With the auto truncation disable, the Raw tab works great for looking at the playlists together with their headers (the cache-related headers are often important and while the content of the media segments do not matter in this context, the headers and the order of the segment GETs with respect to the playlist GETs is important). Then click to a media segment and back to a playlist.
TL;DR There is a tab in Fiddler called "Raw" where if one accidentally clicks on the wrong session, the UI will freeze for a very long time.
Thanks for your time.
The Raw response inspector automatically truncates binary content at 128 bytes, and text content at 262144 bytes. If you disable this autotruncation, you're left at Windows' performance mercy.
Regards,
Eric Lawrence
Telerik
Check out the Telerik Platform - the only platform that combines a rich set of UI tools with powerful cloud services to develop web, hybrid and native mobile apps.

[quote] Fundamentally, it remains the case that inspecting binary content as text is doomed to failure. The HexView should be used for binary content.[/quote]
Good advice, but what to do if I check all requets in the RAW mode, but thet I click to a stream and Fiddler become freezed BEFORE I enter to the RAW mode?
Working with binary data is the ugliest issue in the Fiddler for a lot of years I use it
Does this happen on every stream? Which version of Fiddler is that?
Regards,
Tsviatko Yovtchev
Telerik

Hi,
It happen on every binary stream. On approx. 5 MB streams or higher it is sometimes easier to kill the the Fiddler process than wait while it become alive. I use latest or about latest versions always. Now my version is:
Fiddler Web Debugger (v4.6.2.3)
Built: 14 апреля 2016 г.
64-bit AMD64, VM: 88,0mb, WS: 111,0mb
.NET 4.0.30319.42000 WinNT 6.1.7601 SP1
You've run Fiddler: 150 times.
Running on: xxx:8888
Listening to: All Adapters
Gateway: No Gateway
©2016 Telerik
I am able to see a couple of seconds slow down in the Raw tab on streams of size 50MB and up. It looks like you experience something way more severe, though. Can you refer me to a particular public website where you experience this behavior?
Regards,
Tsviatko Yovtchev
Telerik
