Unexpected Cache-Control Header Transmission in Dual-Server API Setup

Uday Kumar uday.polu at indiamart.com
Wed Jun 28 17:02:53 UTC 2023


Hi Guillaume,

You are right!
varnish is not adding any cache-control headers.


*Observations when trying to replicate the issue locally:*
I was trying to replicate the issue using Local Machine by creating a
Spring Boot Application that acts as API-1 and tried hitting API-2 that's
on Server2.

*Request Flow:* Local Machine ----> Server2 varnish --> Server2 Tomcat

Point-1: When using* integrated tomcat (Tomcat 9) the spring-boot* issue
was *not *replicable [*Just ran Application in intellij*] (meaning, the
cache-control header is *not *being transmitted to Varnish of Server2)

*Point-2:* When *Tomcat 9 was explicitly installed in my local machine* and
built the* corresponding war of API-1 and used this to hit API-2* that's on
Server2, *Now issue got replicated* (meaning, *cache-control: no-cache,
pragma: no-cache is being transmitted to Varnish of Server2*)


Any insights?

Thanks & Regards
Uday Kumar


On Wed, Jun 28, 2023 at 8:32 PM Guillaume Quintard <
guillaume.quintard at gmail.com> wrote:

> Hi Uday,
>
> That one should be quick: Varnish doesn't add cache-control headers on its
> own.
>
> So, from what I understand it can come from two places:
> - either the VCL in varnish1
> - something in tomcat1
>
> It should be very easy to check with varnishlog's. Essentially, run
> "varnishlog -H request -q 'ReqHeader:uday'" on both varnish nodes and send
> a curl request like "curl http://varnish1/some/request/not/in/cache.html
> -H "uday: true"
>
> You should see the request going through both varnish and should be able
> to pinpoint what created the header. Or at least identify whether it's a
> varnish thing or not.
>
> Kind regards
>
> For a reminder on varnishlog:
> https://docs.varnish-software.com/tutorials/vsl-query/
>
>
> On Wed, Jun 28, 2023, 06:28 Uday Kumar <uday.polu at indiamart.com> wrote:
>
>> Hello All,
>>
>> Our application operates on a dual-server setup, where each server is
>> dedicated to running a distinct API.
>>
>> *Technical specifications:*
>> Framework: Spring-boot v2.4 (Java 1.8)
>> Runtime Environment: Tomcat
>> Version: Apache Tomcat/7.0.42
>> Server1 runs API-1 and Server2 runs API-2. Both servers are equipped with
>> an installed Varnish application. When either API is accessed, the request
>> is processed through the Varnish instance associated with the respective
>> server.
>>
>> *Issue Description:*
>> In a typical scenario, a client (browser) sends a request to API-1, which
>> is handled by the Varnish instance on Server1. After initial processing,
>> API-1 makes a subsequent request to API-2 on Server2.
>>
>> The Request Flow is as follows:
>> *Browser --> Varnish on Server1 --> Tomcat on Server1 --> Varnish on
>> Server2 --> Tomcat on Server2*
>>
>> *Assuming, the request from Browser will be a miss at Server1 Varnish so
>> that the request reaches Tomcat(Backend) on server1.*
>>
>> In cases where the browser *does not include any cache-control
>> headers in the request* (e.g., no-cache, max-age=0), the Server1 Varnish
>> instance correctly *does not receive any cache-control headers*.
>>
>> *However, when API-1 calls API-2, we observe that a cache-control:
>> no-cache and p**ragma: no-cache headers are being transmitted to the
>> Varnish instance on Server2*, despite the following conditions:
>>
>> 1. We are not explicitly sending any cache-control header in our
>> application code during the call from API-1 to API-2.
>> 2. Our application does not use the Spring-security dependency, which by
>> default might add such a header.
>> 3. The cache-control header is not being set by the Varnish instance on
>> Server2.
>>
>> This unexpected behavior of receiving a cache-control header at Server2's
>> Varnish instance when invoking API-2 from API-1 is the crux of our issue.
>>
>> We kindly request your assistance in understanding the cause of this
>> unexpected behavior. Additionally, we would greatly appreciate any guidance
>> on how to effectively prevent this issue from occurring in the future.
>>
>> Thanks & Regards
>> Uday Kumar
>> _______________________________________________
>> varnish-misc mailing list
>> varnish-misc at varnish-cache.org
>> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20230628/5a5649a2/attachment-0001.html>


More information about the varnish-misc mailing list