HTTP: Drain event queue after instantiating upgrade analyzer

With configurability through script-land comes the draw back
that we actually need to execute event handlers in the middle
of the parsing process: This might not be the best model, but
the script-side configurability it enables is kind of nice.

This explicit call only matters here when the HTTP reply is
directly followed by some WebSocket message data within the
same network packet, otherwise the queue is drained once the
packet has been completely processed anyhow.
This commit is contained in:
Arne Welzel 2024-01-15 15:39:51 +01:00
parent 37521f58e5
commit 7967ef993b

View file

@ -1344,8 +1344,24 @@ void HTTP_Analyzer::HTTP_Upgrade() {
upgrade_protocol_val->CheckString()); upgrade_protocol_val->CheckString());
auto analyzer_tag = analyzer_mgr->GetComponentTag(analyzer_tag_val.get()); auto analyzer_tag = analyzer_mgr->GetComponentTag(analyzer_tag_val.get());
auto* analyzer = analyzer_mgr->InstantiateAnalyzer(analyzer_tag, Conn()); auto* analyzer = analyzer_mgr->InstantiateAnalyzer(analyzer_tag, Conn());
if ( analyzer ) if ( analyzer ) {
AddChildAnalyzer(analyzer); AddChildAnalyzer(analyzer);
// The analyzer's Init() may have scheduled an event for analyzer configuration.
// Drain the event queue now to process it. This further ensures that other
// events already in the event queue (http_reply, http_header, ...) are drained
// as well and accessible when the configuration runs.
//
// Don't just copy this code into a new analyzer, there might be better and more
// more general approaches.
//
// Alternative proposal from Robin:
//
// Collect all HTTP headers (pattern/names configurable by script land)
// and forward the collected headers to the analyzer via a custom
// configuration method or some in-band channel.
event_mgr.Drain();
}
} }
else { else {
DBG_LOG(DBG_ANALYZER, "No mapping for %s in HTTP::upgrade_analyzers, using PIA instead", DBG_LOG(DBG_ANALYZER, "No mapping for %s in HTTP::upgrade_analyzers, using PIA instead",