I have been trying to start asynchronous tasks from my STM 9.6. For instance, to create HTTP "duplicate" requests.
Let's say a client C contacts load balancer L with request R to talk to server S.
I want L to be able to route R to S. And *then* trigger another HTTP request R', sent to S'. With no penalty for C.
This is something easy to do in TrafficScript using http.request.* commands. Unfortunately, if I add it in a Response Rule, it will delay the answer to C.
I was happy Transaction Completion Rules were introduced because I believed it would fit perfectly. Sadly, after some failed attempts and a look at 9.8 documentation, I found out http.request.* were forbidden at this stage of the processing.
So, I thought about a painfully ugly solution: using custom events emitted at the Transaction Completion time to trigger a UDP syslog packet sent to a local Virtual Server. This VS would be sitting on an UDP socket and parsing the content of incoming segments to tell what request R' to send to S'.
That's when I found out I cannot use http.request.*, even in a Request Rule, if I run a UDP VS...
I am surprised TrafficScript "client" features are that much tied to the protocol of the VS.
Now I know some tools exist to do what I want ( buger/gor · GitHub ) but I really enjoyed the idea of doing it 100% at the STM level.
Any idea that does not involve Java or log tailing?
Solved! Go to Solution.
the TS client functions are bolted implicitly to the VS for a very large number of reasons (ie: you can't access http headers if it isn't an HTTP vserver as the traffic has not been put through the HTTP parser)
That being said, your use case of having a TS trigger an HTTP GET event (ie using http.request.get() ) from a UDP vserver is totally valid and possible. I have used it in the past on a DNS UDP vserver to query a web service to determine what DNS record to return to a client...
In fact I just tested it again to be sure and I was able to trigger an http.request.get() on a DNS vserver with every DNS query that hit it...
You're right, it works! Awesome!
I don't know why I had error messages in the first place, maybe because my http.request.* TS rule was being used by both the UDP Virtual Server AND an HTTP VS, at the transaction completion time (which is prohibited)?
I am happy to see I am not the only one to mix session and session-less protocols, it is a relief for my karma .
PS: Maybe we should document an example of async2sync, this kind of feature is not (well) implemented on open-source load balancing software, and it can prove handy in quite a lot of situations. For instance one could support stale-while-revalidate cache control extension semantics RFC 5861 - HTTP Cache-Control Extensions for Stale Content using this.