Application JSON Requests Do Not Honor X-Magento-Vary Cookie

[kavingas]

Title

Application JSON Requests Do Not Honor Vary Cookie

---

Description

While reviewing the behavior of the Fastly VCL in the Magento 2 extension, I noticed that application JSON requests are not honoring the Vary cookie.

Currently, the logic in [fetch.vcl](https://github.com/fastly/fastly-magento2/blob/master/etc/vcl_snippets/fetch.vcl#L67) only adds Vary cookies for text/html and text/xml content types. As a result, JSON responses are not varying by cookie values, which can lead to serving cached data that does not match the user's session or preferences.

---

Steps to Reproduce

1. Make an application/json request to the Magento API endpoint via Fastly.
2. Ensure the request includes cookies that should vary the response.
3. Observe that the Vary header is not set in the response.

---

Expected Behavior

The Vary cookie should be applied to application/json content types, ensuring correct cache variation based on user session or other cookies.

---

Actual Behavior

The Vary cookie is omitted for application/json responses.

---

Relevant Code Snippet

The logic in [fetch.vcl](https://github.com/fastly/fastly-magento2/blob/master/etc/vcl_snippets/fetch.vcl#L67):

if (beresp.http.Content-Type ~ "text/(html|xml)") {
    set beresp.http.Vary = "X-Magento-Vary, X-Store-Cookie, Https";
}

This restricts Vary cookies to only HTML and XML content types.

---

Proposed Solution

Update the fetch.vcl logic to include application/json in the content types that apply the Vary cookie:

if (beresp.http.Content-Type ~ "text/(html|xml)" || beresp.http.Content-Type ~ "application/json") {
    set beresp.http.Vary = "X-Magento-Vary, X-Store-Cookie, Https";
}

---

Environment

• Magento 2 Version: 2.4.7
• Fastly Module Version: 1.2.223
• Fastly Version: current

---

Additional Context

This behavior could cause issues when serving cached JSON content for APIs that depend on user-specific data. Adding support for the Vary cookie in JSON responses would improve consistency and prevent user-specific cache mismatches.

[kavingas]

PR #731

[rcaril]

Hi @kavingas ,

Thanks for providing this very detailed issue. Upon review, we aren't sure in which scenarios that API calls from the plugin would lead to a non-cached response. Can you provide some use cases / examples that are being solved for here?

[kavingas]

Yes it will impact any AJAX call with json response type.
For an exampole
curl 'https://base_url/search/ajax/suggest/?q=red' \ -H 'Accept: application/json, text/javascript, */*; q=0.01' \ -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36' \ -H 'X-Requested-With: XMLHttpRequest'

[rcaril]

Yes it will impact any AJAX call with json response type. For an exampole curl 'https://base_url/search/ajax/suggest/?q=red' \ -H 'Accept: application/json, text/javascript, */*; q=0.01' \ -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36' \ -H 'X-Requested-With: XMLHttpRequest'

Thanks for this context, we'll review further.

[cchawla8]

Hey @rcaril , I am following up to check the status on this one as customer is awaiting resolution, and it would help if we have an ETA.

Thank You!

[rcaril]

Hi @kavingas - we tested the API call above on few of the shops that we maintain - one of them uses Fastly, others use Varnish. We are confident that none of them cache this API ( on the store with Fastly we can even see MISS, MISS in headers, response time isn't decreasing after repeated request) so we are not exactly sure how Vary helps them in this scenario. We don't believe that the results for their website will be any different after with this PR change.

[kavingas]

@rcaril Did you try with multiple store views with multiple currency setup ?