cancel
Showing results for 
Search instead for 
Did you mean: 

Asynchronous tasks in Traffic Script

SOLVED
sameh
Contributor

Asynchronous tasks in Traffic Script

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.

1 ACCEPTED SOLUTION

Accepted Solutions
aclarke
Frequent Contributor

Re: Asynchronous tasks in Traffic Script

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...

--
Aidan Clarke
Pulse Secure vADC Product Manager

View solution in original post

2 REPLIES 2
aclarke
Frequent Contributor

Re: Asynchronous tasks in Traffic Script

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...

--
Aidan Clarke
Pulse Secure vADC Product Manager
sameh
Contributor

Re: Asynchronous tasks in Traffic Script

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.