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

[Guillaume Quintard]

Not really, I have no tomcat expertise, which is where the issue should be
fixed. That being said, if you can't prevent tomcat from adding the header,
then you can use the VCL on varnish2 to scrub the headers ("unset
req.http.cache-control;").

-- 
Guillaume Quintard


On Wed, Jun 28, 2023 at 10:03 AM Uday Kumar <uday.polu at indiamart.com> wrote:

> 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/4ff96c98/attachment.html>