There was a time when we decided to run plugins on filtered responses. It also birthed the --hard-filter flag to switch that behavior. While refactoring the plugins a little, this method is showing itself as a little doubtful.
The problem:
Context.py and sourcemap.py currently use on the fly methods to manually ensure not to run on filtered requests, regardless of the behavior of the core code. The implemented manual methods are also error prone, as they only check for basic filtering through hide code flags. They ignore show code flags and complex filters through regex statemtents, as well as autofiltered responses. In short: The current implementation is somewhat unreliable.
If we ignore these two, there are a dozen informational plugins that will or will not run on filtered requests. The point is: Letting them run on filtered responses is a waste of resources, too. No information they parse out will make a difference, as they are by definition filtered out from being output.
Lastly, there is linkparser and links.py. These 2 do not have a check for filtered responses, and they are causing more requests. But: They have manual checks for specific status codes to run on, such as 200/300-308. Pretty restrictive, and these have been picked to adhere with status codes that are not filtered out. Meaning, if their logic on whether they run or not was based on unfiltered responses, this would probably be even better, as there may be specific code 200 responses filtered out as default responses, and there may be 405 status codes that they should run on, if they are not filtered.
There was a time when we decided to run plugins on filtered responses. It also birthed the --hard-filter flag to switch that behavior. While refactoring the plugins a little, this method is showing itself as a little doubtful. The problem: Context.py and sourcemap.py currently use on the fly methods to manually ensure not to run on filtered requests, regardless of the behavior of the core code. The implemented manual methods are also error prone, as they only check for basic filtering through hide code flags. They ignore show code flags and complex filters through regex statemtents, as well as autofiltered responses. In short: The current implementation is somewhat unreliable. If we ignore these two, there are a dozen informational plugins that will or will not run on filtered requests. The point is: Letting them run on filtered responses is a waste of resources, too. No information they parse out will make a difference, as they are by definition filtered out from being output. Lastly, there is linkparser and links.py. These 2 do not have a check for filtered responses, and they are causing more requests. But: They have manual checks for specific status codes to run on, such as 200/300-308. Pretty restrictive, and these have been picked to adhere with status codes that are not filtered out. Meaning, if their logic on whether they run or not was based on unfiltered responses, this would probably be even better, as there may be specific code 200 responses filtered out as default responses, and there may be 405 status codes that they should run on, if they are not filtered.