Article page cache ignores query parameters

[valerii-tbb]

The article page cache currently caches content at the path level, ignoring query parameters. As a result, server logic does not run for subsequent requests with different query values, and the same cached page is returned for any variations in the URL.

This affects both layouts and output types. On the first load, the server processes the request and generates the content. After that:

• Query parameters (e.g., ?filter=pets) do not trigger server-side processing.
• Any dynamic content depending on query values is not updated.

At the layout level, data can only be:

• Regenerated on the client-side from the cached server page after rehydration, or
• Populated from scratch client-side, causing a slight delay before the critical data appears on the page.

Workaround: Adding &outputType=some-type can force cache bypass and trigger server logic, but the impact of this hack is unpredictable.

Steps to reproduce:

1. Load the article page with some initial query param:
   /test-story-for-the-gift-guide-5SITTFM4SFEJ3C5DROHH2S23KU/?filter=pets

2. Load the same page with different query parameters, e.g., ?filter=self-care, ?filter=clothing, etc.
   /test-story-for-the-gift-guide-5SITTFM4SFEJ3C5DROHH2S23KU/?filter=self-care
/test-story-for-the-gift-guide-5SITTFM4SFEJ3C5DROHH2S23KU/?filter=clothing

3. Observe that the cached content is returned; server logic does not execute, and any data dependent on query parameters (for us, the values of the meta tags og:title, og:image, and og:description) remains unchanged.

Expected behavior:

• Cache should respect query parameters (or allow specific ones like filter) so server logic runs for different queries.

Also, is it safe to use the &outputType=some-type hack temporarily?

Any guidance or tips on resolving this would be appreciated.

Thank you.

[mfyz]

Ho @valerii-tbb this is indeed very intentional that we don't allow query string parameters other than recognized Arc XP query string parameters.

The reason is this type of approach opens your rendering stack (as well as downstream content platform API) vulnerable to any attacker enumerating and overwhelming your capacity, can result 429 at render level. Arc XP CDN will cover these errors and will still serve stale traffic to your readers (but then your new content will show on your article pages at longer periods of times). This behavior is very dangerous and it is intentionally not allowed at Arc XP.

Output type is allowed but it bypasses CDN cache but on engine render, invalid output type falls back to default. This is actually still dangerous, and let me check with the team how PageBuilder Cache behaves (it maybe still using same "default output type" cached content, so it maybe partially safe, but let me check).

What you can do is to configure these filters as resolver configurations, only allow what's expected in these filter keywords, that will keep the variations of filters to known set of values and cache split. It still increases the capacity to content platform (or your 3rd party content sources), and you can keep this behavior more control and in safe bounds. This changes your URL schema, and filters to be part of path definition, like:

• /test-story-for-the-gift-guide-5SITTFM4SFEJ3C5DROHH2S23KU/filter/self-care
• /test-story-for-the-gift-guide-5SITTFM4SFEJ3C5DROHH2S23KU/filter/clothing

[valerii-tbb]

Thank you, @mfyz. We discussed it within the team and will likely move forward with your suggested approach.