Fiddler freezing when inspecting huge bodys in raw mode

[Fabian]

How can I "not load" the the binary of any requests? 
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--

If I had uploaded a 10MB file it would have been pretty much impossible for me to get all the Content-Disposition parameters. Because as soon as you click on such a big request/response in raw mode, Fiddler freezes trying to load a huge part of the data into the GUI, but usually it stops after x KB and thus doesn't give me the content-disposition parameters below the binary part.

[Eric Lawrence]

Windows' text controls don't work well when you give them non-textual data; they will eventually finish rendering, but it can take quite a bit of time.

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

 

 

[Fabian]

Writing a custom inspector sounds like a lot of work. :/ And the HexView makes makes reading everything way too complicated or is there an option to just break lines where a CR/LF was detected?

[Eric Lawrence]

Writing Inspectors isn't all that difficult, but it's certainly more work than using the ones that are built in.

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

 

 

[Fabian]

I'm a bit shocked that you think that you don't seem to see why the hex mode makes things way less readable. I mean we all learned in school how important it is to make paragraphs because of its effect on the readability. And have you tried to understand an html/js sourcecode in hexview? I bet you would need at least 10 times the time you would need in raw mode.  ;)

[Eric Lawrence]

You might consider using the WebForms Inspector; in your build, it (unnecessarily for you) shows the first 4k of each file, but the parameters are in their own box.

Regards,
Eric Lawrence
Telerik

 

 

[Henric]

I often debug video streaming and accidentally clicking on a media segment when viewing the playlists can be a painful experience (12 seconds to get to the media segment, then another 12 seconds to get back to one of the playlists).  I have a simple response inspector that does its best to display everything as Latin1 (well, Windows-1252) that looks pretty much like the raw inspector (minus editing).

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.

[Eric Lawrence]

Hi, Henric--

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

 

 

[Henric]

First of all, Fiddler is a spectacularly useful tool and I thank you very much for providing it.

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.

[Eric Lawrence]

I'm not sure what problem you're having with viewing text in the Hex view?
 
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

 

 

[Alexander]

[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

[Tsviatko Yovtchev]

Hello Alexander,

Does this happen on every stream? Which version of Fiddler is that?

Regards,
Tsviatko Yovtchev
Telerik

[Alexander]

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

[Tsviatko Yovtchev]

Hello,

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

[Vacoum]

the same, Fiddler freezes while try to view big js files in raw mode. And it's very strange then admin says "write own reader". So fiddler doesn't work if after many years it can not open js files.... I am shocked. And shocked about admin answers.