On another note, while I understand "event [foo] end", and quite like the idea, what are you suggesting "event [foo] end all" to do? Skip all events for the remainder of the connection? Please keep in mind that "event" is a very general command that needs to apply to all the protocols that BIG-IP does or will handle, and is not limited to request/response protocols like HTTP, so "skip all events for the remainder of this request" is probably an unuseful concept.
I do not know the order of events for a request/connection, or what they are named, but bear with me while I give this example:
Say the events are this for the life of a connection and all requests on that connection:
If this would be the EXACT sequence of events, then issuing "event end all" would cause all events to end for one round of firing.
So if you issued "event end all" at event number #4 (HTTP_REQUEST), then event number 4,5,6,7 would all end immediately, and the cycle would continue at event number #8.
So in effect, you might do:
event end all
Which keeps the keep-alive connection, and sets the next event to be HTTP_REQUEST again - or in other words jumps over the other events back to waiting for the client to provide an HTTP_REQUEST event.
Take for example the same events, but the client aborts the connection after getting a HTTP::redirect :
... client aborts connection ...
This is how it might normally progress.
But if you know that the events EVENT_BACKGROUND and EVENT_SOMETHING are going to be executed and you don't want those events to be executed, you would need to tell the BigIP to complete this request cycle and begin at the next request cycle.
Perhaps this is not desired, or something.
Like I said, I do not know the events in between successive HTTP_REQUEST events.
But if there ARE in between events, and you want to skip through these cycle of other events that might otherwise get fired before the next HTTP_REQUEST event, then you essentially want to "even end all".
Or in other words, if I issue "event end all" in the HTTP_REQUEST event, then end every successive event until I get back to this same HTTP_REQUEST event again.
Probably "event end all" would be reserved to experts who know what they are doing.