Hello,
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?
Cheers,
Sameh.
Solved! Go to Solution.
Sameh,
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...
Sameh,
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 .
Cheers,
Sameh.
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.