Command not invoked by HTTP Listener

[v-p-b]

HTTP Listener pipes only invoke their associated commands, when there is some input that can be supplied to them.

This can be problematic, when only command side-effects are wanted, and input is generally ignored. I came across this, when tried to use sleep for rate limiting, because Burp's resource pool implementation is ... not great.

A workaround is to enable passing HTTP headers to commands: since there is always some HTTP header, the command will always be invoked.

I find this behavior unintuitive, hard to debug, and there is no documentation. I think the situation needs improvement, although I don't know what would be the right course of action.

[dnet]

The issue is a bit wider than that: generally speaking, if the pass HTTP headers to command checkbox is unchecked, HTTP messages (requests or responses) without a body are ignored. This has different results in different tools.

Tool	If HTTP message has no body and the above checkbox is unchecked...
Message viewers, commentators, highlighters	Tab is hidden entirely from UI
Context menu items	Menu item is hidden entirely from the relevant submenu
Macros, HTTP listeners	Lets the HTTP message pass through without modification
Intruder payload processors	N/A

One could say, this acts like an implicit filter, as similar things happen if the filter is misconfigured to such a strict state that false negatives get dropped. The question is,

• should this be treated in the same way filter debugging should be treated (e.g. by including some way to debug filters), or
• does this require separate warning above the checkbox way deep in the command invocation dialog?

Would this be a surprise for all tools, or is this something truly unique and applicable to HTTP listeners only?

[dnet]

How about e20d2ec? See screenshot below:

[v-p-b]

Looks nice to me!

[v-p-b]

Fixed by e20d2ec