Forum Discussion
Leslie_South_55
Nimbostratus
NimbostratusRAM Cache - use different cache "buckets" based on URI string
I have what I think might be an impossible challange. I need to be able to use different cache profiles, or "buckets" for a single VS. I will have a single VS, that can be accessed by multiple "groups", and based on the initial GET and a URI string using a ? to determine what "group" you belong to, your content will be seen. This is an eCommerce site using shopping carts and as the different "groups" progress though the site, they will be accessing the same dynamic/static content, but prices will be detemined by the original GET and group assignment.
EXAMPLES:
www.buyawidget.com/groups/path?group=business1
AND
www.buyawidget.com/groups/path?group=business2
business 1 can buy 'widget A' with a price of $5
business 2 can buy 'widget A' with a price of $10
All the page content, except the price and perhaps the business logo, is pulled from the same location (style sheets, images, html, js, etc.)
When business 1 lands on their "portal" the application uses a proxy user to communicate with the front end webserver (weblogic) to determine what unique info is presented in the browser. This proxy user info is internal to the pool member and does not get passed on the wire (from weblogic to the app running on the weblogic server).
The issue is that I need to be able to cache as much as possible, and prevent business 1 from seeing business 2 data, and vise versa. The only unique URL is the very first one, all other URLs will be the same no matter what group you belong to.
There could be potentially hundreds of groups all with different pricing, incintives, etc. The goal is to be able to serve all of these groups and not have to create a portal, or VS for each group as the public URL needs to be the same.
I would appreicate any help on this.
Thanks
5 Replies
- I assume all of these requets have the same Host header? If they are different then you should not have to do any thing as the Host is pary of the URI key.
If the host header is the same then you can use the 'CACHE::uri ' to build a logical uri that ramcache uses to key the cached document. So in your case, the rule might look like 'CACHE::uri [HTTP::uri]$my_session_string' where the session_string is a string derived from the user specific application.
This forces the to store the documents under the different URI without actually changing the URI on the wire. This logic should be employed in HTTP_REQUEST event. 
Leslie_South_55Forgive the stupid questions, but by host header, are you referring to the actual host as in the "Host: x.x.x.x" in the HTTP GET request? If so, then the answer is yes, they are the same. All requests will be going to a single VS, that points to a single pool with 3 members.
If I understand the 2nd part correctly, I can set a CACHE::uri based on each request and if repeated requests match that it will pull from that cached data? How do I tie, in my example, the string all the way through the session when the first URL is the only URL that has the unique ID? And can I dynamiclly assign that string without specifying the actual unique ID and possibly use a varrible?- Leslie_South_55To provide a bit more clarification, when any business/group selects widget A, the URL would be something like
www.buyawidget.com/products/widget-A.htm
and the business/group logo would be put on the page, and whatever price they are elligible for would also be populated. I need to be able to provided cache responses that do not cross contaminate each other, but could have the same name. - Yes I am referring to the HTTP Host header.
You will have to maintain a HTTP session where the magic string will be stored. There are variety of ways in which you can do this.
1) Store it as a variable after the users has visited the first URI. While this is the simplest approach, its limited to application that authenticate every connection. It that's what your application does then that should work.
2) If you already have a HTTP session, you could store the information in a HTTP cookie.
3) If your application is already creating a session using a cookie, and you don't want to add another cookie, you could store the information as a persist data that's keyed using the cookie value.
There are examples of all of these in the forum. Good luck! - Leslie_South_55I really appreciate the help thus far. I still have a long way to go to understand the 3 options you mention, but I will continue to research those on the forum.
One addtional question is, will I need to maintain multiple cache profiles so I can isolate the cache items by session? so I dont have business 1 pulling cache files from business 2's data?
![\"F5](\"https://www.f5.com/content/dam/f5/f5-logo.svg\"){kind=logo}
