Last month quite some time before 18.104.22.168 firmware shipped I did coproc2gatewayscript posting here.
I made use of the fact that writing to "temporary:" folder was a possible location of a GatewayScript file.
My colleagues read that and closed that "hole", because GatewayScript files should be located under either "local:" or "store:".
First I was a bit frustrated, but then I realized another problem of my solution:
I made use of <dp:dump-nodes> to store a text node into "temporary:" folder.
There is no way to avoid escaping of '<' as '<' and '&' as '&' with <dp:dump-nodes>.
Also, if you look into above referenced posting, I had to make use of
<dp:url-open target="http://255.255.255.254" timeout="1"/>
in order to wait for some time (1 sec) to make sure that "temporary:///js" was written before GatewayScript action can be executed and finds the current GatewayScript file there, not a nice "hack".
OK, where to go from here?
I had to store a file under "local:" or "store:", and that is only possible via XML management interface.
And that is exactly what I did.
The solution on how to do that was easy, just made use of Accessing XML Management interface from within a stylesheet posting.
You will have to
- create a new user named "soma" and ssl-proxy-profile "xslt-ssl" as described in that posting
- import service export attached to this develperWorks forum posting
change MPGW coproc2gatewayscript FSH to a different port if this is not the 1st installation on a box
(allows for multiple developers using coproc2 GatewayScript endpoint on same box without interference)
and that's it.
Because its a new service export I added some fancy/useful stuff.
22.214.171.124 firmware provide "Extended Latency records" in addition to "Latency records":
An Extended Latency record gives values for each single action!
And that allows to get execution time for GatewayScript action alone at millisecond level.
All that is needed is a log target subscribing to "extlatency" category at "information" level.
And such a logging target ("ExtLatency") is part of the service export.
Latency log entries as well as Extended latency log entries are only written for services with real backend.
No skip-backside is allowed. That is the reason why "echo" mode HTTP service "coproc2ptlb" listening on port 2229 is also part of the export.
And finally MPGW "coproc2gatewayscript" is contained in the service export.
This is an example entry from "logtemp:///ExtLatency.txt":
Wed Jun 25 2014 09:57:20 [0x80e007ad][extlatency][info] mpgw(coproc2gatewayscript): tid(70321)[126.96.36.199]: ExtLatency: TS=0,HR=0,BR=0,PS=0,AXF=41,AGS=42,PC=42,CS=42,HS=42,BS=42, == HR=42,BR=42,PS=42,PC=42,HS=42,BS=42,TC=42, [http://188.8.131.52:2227/]
AXF=41 is completion of transform action storing GatewayScript into "local:///temp.js".
AGS=42 is the completion time of GatewayScript action [in millisecond].
Therefore aes.demo.js from previous blog posting took 1ms to complete.
Multi developer use on same box
The GatewayScript source file sent by "coproc2" client gets stored under "local:///temp.js".
This may be a problem if multiple users use GatewayScript coproc2 endpoint at exactly the same time.
Solution is simple:
- create new application domain for 2nd and further installations
- import service export into that domain
- HTTP service on port 2229 will be down, but that is fine since the one installed first is up
- Log target is fine and stores to "logtemp:///ExtLatency.txt" in that domain
- you just need to change MPGW FSH port from 2227 to some other available value
Have fun with GatewayScript (and coproc2),