ERR_RESPONSE_HEADERS_TOO_BIG with Keep Cart plugin for really large baskets

[necroside]

Hi,

We am having an issue with our site, when a customer is trying to edit the cart contents on really large carts (50 different products or more) he get's an screen with the error: ERR_RESPONSE_HEADERS_TOO_BIG. When you reload the page you see that the cart contents has been updated. This happens on Chrome only.

I disabled the Keep Visitors Cart option in the Configuration->Sessions area and it seems to work, but we are losing sales now. (A lot of sales).

I changed some server values (like LimitRequestFieldSize) to a bigger size and this doesn't solve the problem either.

So. Two questions,
Is there a way to solve this? or
Is there a module or contribution that saves the cart to the database or a flat file instead of a cookie so headers can be smaller?

INFO:
Site: https://www.quikdrawers.com/ (Lots of plugin and custom code in there).

Thanks for any help and forgive the bad English.

Best regards.

[mc12345678]

I used chrome to inspect a ZC 1.55e site that was using the zen responsive classic template, has a few plugins that add various javascript files to the load including paypal incontext which had a response header made of 28 pieces of data. I added maybe 50ish different default products. Never did I see an issue or change in the cookie content, so I would say that the cookie part is not your issue; however, every image that is loaded, every javascript file, css file, etc... adds response header information. As such I would advise to find ways to reduce the objects that send response headers.

Now that's from a brief review of 1) such a problem appearing to occur with chrome (yet another chrome issue) more than other browsers, that the reported issue is with response headers specifically and inspecting the network traffic related to a page load where the response headers could be viewed.

I did notice when visiting the shopping cart page of your site that there was some minor mixed content (image to the better business Bureau is http: instead of your page(s) load using https: I further validated that the bbb site supports https: so I would think they would appreciate it if you linked to them in that manner.)

Alternatively you may want to limit the quantity of items that can be added to the cart and request multiple purchases perhaps if they are using Chrome only... it's their "doing" to have that limit.

Oh and another thing, I noticed that the zenid stayed on my browser link which indicates you have some sort of session related issue which may be because of the change(s) made.

As for the session data, it already is stored in the database with a minor cookie to link the visitor to the database content that is unless such cookie capability is disabled.

[DrByte]

I'm gonna disagree with mc12345678 here.

I suspect the problem is indeed with the KeepCart plugin, as it will create a relatively large cookie with a very large cart ... particularly since a lot of your products are constructed from complex attribute combinations.

Cookies are limited to 4095 characters (some will say 4093, but that's trivial in this context). So, when your visitors prepare a sizeable configuration of basket contents they could indeed exceed that threshold.

Of course, if they create an account or login then the KeepCart cookie isn't needed at all as their entire basket is stored in the database instead, and preserved between logins (but only shows up while logged in).


It'd be ideal to have the KeepCart plugin rewritten somewhat, but there are some technical complexities that need considering.

As a stop-gap you could encourage your customers to login if they want their shopping selections to be preserved. Maybe even encourage it with some sort of incentive. And, if you combine that with an abandoned-cart-recovery plugin to use for follow-up then you can reach out to those customers who may have forgotten what they put in their baskets. In the end this may be even better for business.

[swguy]

As an alternative, you might also look at Save for Later.
https://www.zen-cart.com/downloads.php?do=file&id=872

[necroside]

Thanks a lot for your comments, indeed Dr Byte was right, the problem is with the plugin itself, I am deciding between doing a small modification to the plugin, let's say have the cookie to store an unique value (to identify the cart) and have the cart items updated in a database table.
Or trying to get the customers to login and save their carts, the latest has a big upside I am trying to figure out, what if the session is lost before login, I mean, let's say someone adds 10 products to the cart, then he has to pick up an important call and then comeback to the site, if they weren't logged all of their cart information will be lost.
I will let you know if I can solve this.