Before I did the zip2html posting last December I had a solution without the cool execution of an attached stylesheet.

I did extract all files needed, and because storing on local filesystem was not possible without going through xml-mgmt,
made use of a self-implemented "file cache". In difference to normal backend response caching in that scenario the
files are available on the "client side" and caching these was not that easy.

But because I finally came up with a purely attachment based solution for zip2html tool there was no need for the "file cache" anymore.

I had discussions with a Techsales colleague at that time, and he just told me that he needs to cache client data and asked for my cache.

So I seperated out my "client request cache", reworked it and post it here today for anybody who needs to cache client data on DataPower.

By default the document count is 5000 (which you may want to reduce) and the document cache size is 0 (disabled, you need to increase).
The maximal size of a document cache is 161MB, but keep in mind that anyconfigured document cache memory is lost for transactiuons.
I did set document caching to fixed with time to live (TTL) of 59 seconds for URLs matching "*cache*", all other URLs are not chached.

Before going into the details, that is what "you get".
First we cache (POST) the document with content "test123" under URL .../cache/0001.
Then we retrieve it (GET) two times successfully.
The big image Screenshot.png gets cached under URL .../cache/002 then.
And two more get requests get it back from the cache.
The "word-count" (wc) commands prove that the received and original sizes (273657 bytes) are identical:

And this is screenshot of "Status->XML Processing->Document Status" status provider after above commands.
Here we can see that the small "test123" document gets cached as one document.
The big Screenshot.png gets cached as 3 parts (only last part less than 127.000 bytes in size).
And the concatenated complete compressed base64 string for retireval under URL .../cache/002:

Again, before going into the details, find a 3.8.2.6 domain backup and its zip2html tool output attached here.

The three files stored in local:/// directory of that domain (shown further below) are available inlined in the "(all)" link of zip2html file!

Since HEAD is not really helpful in getting client data put into DataPower document cache, only GET remains.
So a caching service on DataPower needs to "send" the client data using GET to a helper service on the same box to do the caching.
Unfortunately the HTTP header size is limited, so although compressing the client data first it may not fit into a single request.

The solution I have implemented is this:

Client:

sends some (binary) data of arbitrary size to DataPower for caching under a specific URL

extract the 127.000 bytes received by a "part" GET request and "return" them which stores them into document cache

when receiving a "combine" GET request from 1st service, reading all 127.000 byte parts for that request from
document cache and "return" their concatenation, which stores the whole compressed document into document cache

So what the file cache does is storing files from the client side into DataPower document cache circumventing the problem
that you cannot cache files by a POST request -- that's all -- see the demonstrations above, and try out yourself !

I did import and test the above attached backup on 3.8.1.20, 3.8.2.6, 4.0.1.4 and 4.0.2.5 firmwares.

(for me this is the first time, that all rule "matches" are HTTP-method matches (for GET or POST))