Pending Review
Last Updated: 06 Feb 2020 13:44 by ADMIN
S
Created on: 30 Jan 2020 03:06
Type: Feature Request
1
Fiddler Non-destructive Filtering

It'd be extremely useful if Fiddler could have the ability to do filtering non-destructively, where filtering doesn't drop data/entries/lines altogether, but rather, merely hiding them from display.

This enables the ability for you to do multiple levels/layers/slices of filtering, as there's very often a need for doing on any given capture session. Currently, however, when you filter on something, the capture data gets dropped from the data/result set, lost altogether.

Process Monitor by Microsoft/Sysinternals has this ability, and it's extremely useful, allowing you to not only do layers of filtering, but also allowing the ability to traverse back up the "stack" 1..n filter layers, and if/when needed, able to un-filter all the way back up to baseline of all capture data shown (and without having to re-load a session save).

Procmon also has the ability to "Drop filtered events", which when enabled does destructive filtering, dropping any non-filter-matching packets from that point forward:

This would also be handy to have, but not crucial; much more beneficial/important is the ability to filter non-destructively.

3 comments
ADMIN
Simeon
Posted on: 06 Feb 2020 13:44

Hi,

Thanks for the request, because it helps us create a better Fiddler. Actually, the non-destructive filtering feature will be available for Fiddler Everywhere and it will be released soon. If you are subscribed for the insider program, you will get it first.

Regards,
Simeon
Progress Telerik

Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Feedback Portal and vote to affect the priority of the items
S
Posted on: 05 Feb 2020 00:44

Thanks for the response, Eric. Respectfully, however, would the memory usage not be any different than without this ability enabled? Since a standard capture would already be capturing from the entire "straw", so to speak, and as such, visually-only filtered entries/packets would just be a matter of hiding their entries from going out the display buffer. Unless you're implying that by having non-destructive filtering enabled, a user might forget about it and thus let a capture run on for longer based on the fewer amount of entries than expected displayed on screen?

Of course, there will be cases where one doesn't want all packets kept around, such as preset filters before capture has even begun. A non-destructive filter capability could take this into account and only filter non-destructively relative to whatever the starting baseline filtering established at the beginning of the capture.

Perhaps the simplest solution would be how Process Monitor approaches this: offering a simple checkbox for the user to choose whether or not to keep all filtered packets or not, i.e., enabling or disabling non-destructive filtering.

Another option to assist this would be a rolling capture buffer -- a user defined capture buffer size parameter, with the option to have the buffer only hold onto the most recent X entries or capture size (in memory).

Another option to assist this would be the ability to choose whether to capture/buffer to memory or to disk, giving the user the option to select not only an on-disk cache/paging file, but even across multiple drives (as Procmon does).

But I think the simplest solution for this would be a checkbox allowing the user to choose whether Fiddler should hold onto everything during this particular capture session or not, to filter non-destructively or not, e.g., Process Monitor's "Drop filtered packets" option.

Eric
Posted on: 01 Feb 2020 03:27

This request comes up periodically, and it's an understandable user-scenario.

The problem is that unlike process monitor events, Fiddler sessions can use up a *LOT* of memory. Like, gigabytes-per-minute. As a consequence, keeping this traffic around can cause the system to quickly run out of memory, which leads to huge swap files and miserable performance for everything.

There are doubtless some ways that a filter-but-don't-remove option could be offered, but it can't be the default, and is probably most suitable when examining a SAZ file vs. during a live capture.