Storm Forecast Blog

On APIs, Load Testing, Performance and StormForger.

Cookie Domain Mapping

Cookie Performance testing often happens on non-production systems, like a QA or dedicated "perf" environments. In some cases it is easier to directly access those systems for testing instead through a load balancer serving traffic under a shared domain. This approach leads to a typical problem though: Cookie domain mismatches and lost sessions.

Cookies!

Let's say you are running an ecommerce site and have a QA environment under shop.qa.example.com. The shopping cart is managed by dedicated service running under cart.qa.example.com. In production the entire shop, including the cart component, is served from the same domain under https://example.com. Requests to /cart/* are routed to the shopping cart, while the rest is routed to the shop system.

In production, when everything is served under the same domain, you don't have any problems. For performance testing there can be any numbers of reasons to directly test against upstream systems. There is usually one problem though: Cookies. The standard cookie rules will not send cookies set for one system to another if the domain does not match.1

For this reason, we recently added a small feature called "Cookie Domain Mapping". Cookie Domain Mapping allows to change the rules how cookies are handled in a StormForger test by providing mapping configuration for the domain property of cookies.

How can we apply this to our ecommerce example we've already described? The goal is, that cookies set by either system {shop,cart}.qa.example.com have to be available to every other system. To achieve this, you can provide a mapping like this:

session.setOption("cookie_domain_map", {
  "cart.qa.example.com": "shop.qa.example.com",
});

Cookies set by {shop,cart}.qa.example.com will be handled like as if they were set by shop.qa.example.com (storing cookies). The same happens for the decision logic if cookies should be send back to the server (reading cookies). Note that cookies won't be sent to other domains, like static.qa.example.com.

Example

To get a more complete picture, let's take a look at a simple user journey with three steps: Visit start page, view a product and add a product to the shopping cart.

Visit start page: A new client visits the start page. In the background a session cookie is generated and returned with a Set-Cookie header:

session.get("http://shop.qa.example.com/");

Nothing special happens here in terms of cookie handling.

View a product: The client now visits a product page. The value from the session cookie is for example used to fill the "recently viewed articles" list.

There is also no special treatment required for this, as the start page was served from the same domain and cookie handling works automatically in those cases:

session.get("http://shop.qa.example.com/4711");

Add product to shopping cart: Now we want to add the item to the shopping cart by performing a POST request. The session cookie is required to internally associate the cart to the correct user. But the domains do not match. We have to configure a domain map to send the cookie regardless of the mismatch:

session.setOption("cookie_domain_map", {
  "cart.qa.example.com": "shop.qa.example.com",
});

session.post("http://cart.qa.example.com/add", { payload: "ean=4711" });

🎉

Conclusion

Cookie Domain Mapping is a simple feature to manipulate the handling of cookies being saved and looked up by simulated clients in a StormForger test. It allows to make Cookies seamlessly work across different domain names which can become handy when testing non-production environments.

Check out our documentation on "Cookie Domain Mapping" to learn more.

  1. This is of course a gross simplification. 😀 If you really want to understand how this works, check out RFC6265: HTTP State Management Mechanism. As it turns out, handling cookies correctly is surprisingly complex… 😞 

Create repeatable Performance & Load Tests easily using our JavaScript DSL to verify your HTTP APIs. StormForger enables you to do continuous performance testing to make the web a faster place.

Learn more...
definition.setTarget("API.EXAMPLE.COM");

definition.setArrivalPhases([
  {
    duration: 5 * 60,  // 5min in seconds
    rate: 1.0,         // clients per seconds to launch
  },
]);

definition.session("hello world", function(session) {
  session.get("/", { tag: "root" });
});

Learn More and Become a Customer

You may want to start load & performance testing immediately, learn more about StormForger or talk to a human – anyhow: we are here to help. 👋

Icon Sign up Start with our free-tier and run your first tests in minutes. All features enabled. No credit card required.
Icon Schedule a demo Schedule a personal, customized demo. We'll show you around and introduce you to StormForger.
Icon Talk to a human To build and run reliable applications is complex – we know. Schedule call and we’ll figure things out.

We are using cookies to give you the best online experience. If you continue to use this site, you agree to our use of cookies. By declining we will disable all but strictly required cookies. Please see our privacy policy for more details.


Accept Decline

AWS APN Avanced Technology Partner
AWS APN Avanced Technology Partner