Hi Tin, I can't speak to whether Y! plans to open source the cookie remap plugin but I was author of that plugin at Y! and can give some generic pointers. The plugin itself is is a bit Y! specific, so there may be some difficulties getting it released but I can speak to the general idea behind the plugin. My comments below assume a reverse proxy setup.
With any remap plugin you are essentially changing the way TS behaves when it receives a request, moving from a static mapping of url A-> origin B to a dynamic choice of origin based on some aspect(s) of the request. In this case, the goal is to change which origin server will handle the request based on the request cookies from the client. There are many useful possibilities for a plugin like this. One example might be sending the request to a "static" origin server if the request appears to not require personalized content (iow, valid session cookie(s) are not present). Another example might be "sticky" sessions where a hash of the cookie string always sends you to the same origin server. There are many possibilities. Imagine someone wanting a combination of both of these. For a successful plugin, I think you would need a couple a key ingredients: * a decent cookie parsing library * some configuration mechanism [1] (optional) * determining what aspects of the Cookie you are interested in (presence,non-presence, value, hash, range of values,....) For the code itself: You basically (optionally) parse your config file in remap startup (tsremap_new_instance [2]) where you have access to the parameters from remap.config (importantly: @pparam). A typical single remap plugin config would look something like: (remap.config): map http://www.hostname.com http://default.origin.hostname.com @plugin=/path/to/cookie_remap.so @pparam=/path/to/config/file Then, for each request matching www.hostname.com, you will receive a callback into your plugin's tsremap_remap(...). Included in that callback is a TSRemapRequestInfo struct. Inside the struct are the standard TS non-null-terminated strings (with sizes) for stuff like the Host header, path, query string, etc. One of these is rri->request_cookie.You will want to parse that cookie according to the RFC, perform some magic based on your config/business logic (which you can get at by casting ih to something more interesting (probably some struct you created and setup in tsremap_new_instance)). Now, the interesting part: based on what you want to do with the request, you write data into rri->new_* [2] and return a non-zero value from tsremap_remap(). This return value indicates you have chosen to remap the request rather than fall back to the default (in this example, you would fall back to http://default.origin.hostname.com). For debugging, i recommend running with at least: traffic_server -T "url_rewrite" to see what the remap 'processor' is doing with the request. You should also be able to use the standard Debug("my_plugin","I am doing stuff with your request now..."); in your remap plugin code which would then allow you to debug TS with something like: traffic_server -T "url_rewrite|my_plugin" Hope this helps answer some of your questions, --Eric [1] I chose YAML using syck to parse the config but that depends entirely on your needs [2] https://svn.apache.org/repos/asf/incubator/trafficserver/traffic/trunk/proxy/RemapAPI.h On Mon, Nov 23, 2009 at 1:23 PM, Tin Zaw <t...@attinteractive.com> wrote: > Hello, > > I was reading in SDK doc about yts.cookie.remap plugin but I cannot find it > in the source tree. I am trying to use Traffic Server with cookie based > mapping/redirection. > > Is there any plan to release that code soon? If not, any good examples or > advice on how to write such plugin? > > Thanks in advance! >
