During the Ajax call to submit order in one-page checkout process, I'm getting cookie "CUSTOMER_SEGMENT_IDS" multiple times, with "Deleted" as value. This is causing header size to go much beyond the allowed limit (more than 8k in some scenarios), and thus causing error in placing the order. It is only happening for customers having more than 4 addresses in their address book.

I have located it to the Enterprise_PageCache_Model_Observer where this cookie is getting set by core Magento code. There is no customization present in store for dealing with cookies or customer segments.

I'm planning to re-write this class to remove all "Deleted" cookies from response altogether. Is there any drawback of this approach that I should be aware of ? All I could find similar to this is this question : Multiple Cookies in Ajax call but, there is no activity in that question.

Anyone else experienced this problem earlier ? Is there any particular reason for this behavior in Magento code-base ?

  • Were you able to resolve this? – TylersSN Jan 30 '18 at 20:15

Magento 1.x EE FPC saves entire page into the cache. But there are some sections in the page that need to be rebuilt during customer journey. E.g. If you add a product to cart the minicart should be updated.

There is no point having FPC if we invalidate entire cache each time customer add a product to the cart. Since the cart is visible in all the pages we have to flush the entire cache in order to see the updated cart.

To address this issue they have introduced cache containers. You can find these containers under app/code/core/Enterprise/PageCache/Model/Container.

What it does is rebuild the specific section of the page by checking the cache id. The id can be a combination of several variables, cookies, and constants. The purpose of this id is to invalidate the section cache when required.


If you check Enterprise_PageCache_Model_Container_Minicart the cache id is generated using the following method

public static function getCacheId()
        $cookieCart = Enterprise_PageCache_Model_Cookie::COOKIE_CART;
        $cookieCustomer = Enterprise_PageCache_Model_Cookie::COOKIE_CUSTOMER;
        return md5(Enterprise_PageCache_Model_Container_Advanced_Quote::CACHE_TAG_PREFIX
            . (array_key_exists($cookieCart, $_COOKIE) ? $_COOKIE[$cookieCart] : '')
            . (array_key_exists($cookieCustomer, $_COOKIE) ? $_COOKIE[$cookieCustomer] : ''));

The each time the quote get to update it delete this cache id from the cache. Enterprise_PageCache_Model_Observer::registerQuoteChange. In the next immediate request, the system can not find the content related to this cache id. So it regenerates the contents and saves to the cache. Enterprise_PageCache_Model_Container_Minicart::_renderBlock

The CUSTOMER_SEGMENT_IDS cookie is used in Enterprise_PageCache_Model_Container_Banner container. Banners can be displayed based on customer segments. Customer segments can be created using various conditions including customer address variables. The length of this cookie vary depends on customer segments.

The purpose of this cookie is to invalidate the cache sections and display banners based on customer segments. If you are not using this functionality you can remove it. The recommended solution is to increase the header size from the server.

Hope this helps!

  • Thanks for the inputs Kavinga, but I'm not dealing with caching and banners here. It's default one-page checkout process, so FPC is not supposed to work here. Cookies are being returned as a response of final Ajax call in one-page checkout process, there are no banners there as well. Increasing the header size would be a temp solution, as there is no guarantee that it won't get beyond the new header limit. – Prateek Jun 9 '17 at 3:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.