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.

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.