Okay, this may be a little hokey, but I think I have something that'll work.
when HTTP_REQUEST {
set vip "access-test-internal-vs"
prepare the sideband call
set conn [connect -timeout 3000 -idle 30 -status conn_status $vip]
send the sideband call
log local0. "sending sideband call"
set send_info [send -timeout 3000 -status send_status $conn [HTTP::request]]
log local0. "sending 204"
HTTP::respond 204 content "OK"
log local0. "closing sideband"
close $conn
}
This rule initiates a sideband call to an internal virtual server, immediately closes it, and then sends a 204 to the client. This "external" virtual server has no pool. The internal virtual server is responsible for forwarding the traffic to a pool.
For testing, the internal virtual server has the following iRule:
when HTTP_REQUEST {
log local0. [HTTP::request]
}
when HTTP_RESPONSE {
log local0. "here"
}
And here's what I get in the logs:
external-rule : sending sideband call
external-rule : sending 204
external-rule : closing sideband
internal-rule : GET / HTTP/1.1 User-Agent: curl/7.16.4 (i586-pc-mingw32msvc) libcurl/7.16.4 OpenSSL/0.9.8d zlib/1.2.2 Host: 10.70.0.196 Accept: */*
internal-rule : here
So it would appear that the 204 response is sent before a response is generated. Admittedly, setting up a sideband connection per request may not perform as well as simply sending to a pool, but it'd need to be tested to be sure.