This posting is mostly useful for firmwares <22.214.171.124
For firmwares ≥126.96.36.199 see Cache response to POST and PUT requests in InfoCenter.
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.
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.
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.
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:
$ curl --data-binary "test123" http://dp2-l3:7071/cache/001 $ curl http://dp2-l3:7071/cache/001; echo test123 $ curl http://dp2-l3:7071/cache/001; echo test123 $ curl --data-binary @Screenshot.png http://dp2-l3:7071/cache/002 $ curl http://dp2-l3:7071/cache/002 -s | wc 894 4787 273657 $ curl http://dp2-l3:7071/cache/002 -s | wc 894 4787 273657 $ wc Screenshot.png 894 4787 273657 Screenshot.png $
This is screenshot of "Status->XML Processing->Document Cache" status provider after above commands, 5 documents cached:
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:
- only GET (9.3) and HEAD (9.4) method responses are cacheable
- POST (9.5), PUT (9.6) and DELETE (9.7) method responses are not cacheable
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.
- sends some (binary) data of arbitrary size to DataPower for caching under a specific URL
- requests a cached version for a given URL
DataPower "cache" service with same XML manager (same document cache as "cache-loopback" service) :
- compresses received data by dp:deflate() resulting in a big base64 string
- splits that base64 string into parts of size 127.000 bytes (in order to get them through the HTTP header "eye of the needle")
- sends each of these parts to 2nd DataPower service via GET calls and passes the 127000 bytes in HTTP request header
- sends a final GET request for combining all those parts on chained DataPower service for later retrieval
- when receiving a "normal" GET request for a file in cache, return that file (uncompressed of course)
chained DataPower "cache-loopback" service with enabled document cache (same XML manager as "cache" service):
- 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 !