Order Attribution cookies causing intermittent HTTP 400

  • Nazar

    (@zaaz28)


    1 day, 3 hours ago

    Hi,
    We’re seeing intermittent 400 Bad Request errors on storefront pages. Origin server confirmed healthy – an anonymous, cookie-less request to any product page returns 200 OK and renders fully. The failure is request-specific, tied to the size of the Cookie request header, which is hitting the server’s header-buffer limit (8192 bytes on Apache/nginx).

    Root cause identified:
    Order Attribution (which bundles sourcebuster.js — wp-content/plugins/woocommerce/assets/js/sourcebuster/sourcebuster.js) sets two cookies that store the entire landing-page URL and the entire referrer URL as plain text, not a truncated value, not a hash, not a reference ID:

    • sbjs_current_add — full “current” landing URL
    • sbjs_first_add — full “first ever” landing URL

      Example sizes we’re capturing from real visitor sessions:
    • sbjs_current_add = 783 bytes
    • sbjs_first_add = 781 bytes

      Our site with:
    • Faceted/filtered navigation producing long URL paths (our filter URLs routinely run 120–180+ characters, e.g. /product-category/engagement-rings/style/vintage/filters/center_stone_type/morganite/diamonds/natural-diamond/material/14k-white-gold/style/side-stones-vintage), and
    • Paid traffic landing with long UTM/click-ID query strings appended to those URLs (?utm_source=...&utm_campaign=...&fbclid=...&gclid=...)

    these two cookies alone can approach or exceed 1.5KB combined, and they compound with every other marketing/analytics cookie set on the page (GA4, Meta Pixel, TikTok, Pinterest, etc.). In our own audit, the total Cookie header for a real returning visitor measured ~8,018 of 8,192 bytes (97.9%) across ~66 cookies, with sbjs_current_add/sbjs_first_add as the two single largest contributors (https://prnt.sc/pArgJ_jkUgjy). Any additional cookie, or a slightly longer landing URL on the next visit, pushes the request over the server’s header limit and it gets rejected with 400 before WordPress even loads — so nothing in wp_die or any app-level hook can catch or log it.

    Because the cookie size fluctuates with the length of the URL a visitor happens to land on, the error is intermittent and hard to reproduce consistently — it depends entirely on traffic source and site URL structure, not on a fixed condition.
    We can raise large_client_header_buffers/LimitRequestFieldSize server-side as symptom relief, but that doesn’t address the fact that the cookie payload will keep growing as more marketing tags are added over time.

    Any idea how it can be solved w/o changing large_client_header_buffers/LimitRequestFieldSize?
    I know that I can disable Order Attribution, but it’s also good data stored here for marketing, so I prefer to keep it.

    Thank you!

Viewing 1 replies (of 1 total)
  • Plugin Support shahzeen(woo-hc)

    (@shahzeenfarooq)

    2 hours, 13 minutes ago

    Hi @zaaz28!

    Thanks for providing such a detailed explanation of the issue and for sharing the investigation you’ve already done. I understand the concern, especially since the errors occur before WordPress loads and appear to be related to the size of the Cookie request header.

    Based on the behavior you’ve described, I’d recommend reporting this to our developers on the WooCommerce GitHub repository so they can investigate whether the Order Attribution cookies could be handled differently to avoid unnecessarily large cookie payloads while still preserving the attribution data:

    WooCommerce GitHub repository

    When creating the report, please include the details you shared here, particularly the cookie sizes, the sbjs_current_add and sbjs_first_add values, the 8,192-byte server limit, and the fact that the request is rejected before WordPress loads. This should give the developers enough context to investigate the underlying behavior and advise on the best approach.

    I would not recommend changing or modifying large_client_header_buffers / LimitRequestFieldSize as the permanent solution, since that only increases the amount of data the server accepts and doesn’t address the growing cookie payload.

    As a temporary workaround, however, you can consider increasing the server’s request-header limit so that legitimate visitors aren’t receiving 400 errors while the underlying issue is being investigated. Your hosting/server administrator should be able to make that change safely based on the server configuration.

    I’d suggest keeping Order Attribution enabled for now if the attribution data is important to your marketing workflow, and allowing the developers to review whether the cookie storage can be optimized without losing that data.

    Thanks again for the detailed report this is useful information for investigating the issue.

Viewing 1 replies (of 1 total)

You must be logged in to reply to this topic.