<div dir="ltr">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;").<div><div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>-- <br></div><div>Guillaume Quintard<br></div></div></div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 28, 2023 at 10:03 AM Uday Kumar <<a href="mailto:uday.polu@indiamart.com">uday.polu@indiamart.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Guillaume,</div><div><br></div><div>You are right!</div><div>varnish is not adding any cache-control headers.</div><div><br></div><div><br></div><div><b>Observations when trying to replicate the issue locally:</b></div><div>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.</div><div><br></div><div><i>Request Flow:</i> Local Machine ----> Server2 varnish --> Server2 Tomcat</div><div><br></div><div>Point-1: When using<b> integrated tomcat (Tomcat 9) the spring-boot</b> issue was <b>not </b>replicable [<b>Just ran Application in intellij</b>] (meaning, the cache-control header is <b><font color="#000000">not </font></b>being transmitted to Varnish of Server2)</div><div><br></div><div><b>Point-2:</b> When <b><font color="#ff0000">Tomcat 9 was explicitly installed in my local machine</font></b> and built the<b> corresponding war of API-1 and used this to hit API-2</b> that's on Server2, <b><font color="#ff0000">Now issue got replicated</font></b> (meaning, <b>cache-control: no-cache, pragma: no-cache is being transmitted to Varnish of Server2</b>)</div><div><br></div><div><br></div><div>Any insights?</div><br clear="all"><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><font color="#000000">Thanks & Regards</font><div><font color="#000000">Uday Kumar</font></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 28, 2023 at 8:32 PM Guillaume Quintard <<a href="mailto:guillaume.quintard@gmail.com" target="_blank">guillaume.quintard@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Hi Uday,<div dir="auto"><br></div><div dir="auto">That one should be quick: Varnish doesn't add cache-control headers on its own.</div><div dir="auto"><br></div><div dir="auto">So, from what I understand it can come from two places:</div><div dir="auto">- either the VCL in varnish1</div><div dir="auto">- something in tomcat1</div><div dir="auto"><br></div><div dir="auto">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 <a href="http://varnish1/some/request/not/in/cache.html" target="_blank">http://varnish1/some/request/not/in/cache.html</a> -H "uday: true"</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Kind regards</div><div dir="auto"><br></div><div dir="auto">For a reminder on varnishlog: <a href="https://docs.varnish-software.com/tutorials/vsl-query/" target="_blank">https://docs.varnish-software.com/tutorials/vsl-query/</a></div><br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Wed, Jun 28, 2023, 06:28 Uday Kumar <<a href="mailto:uday.polu@indiamart.com" target="_blank">uday.polu@indiamart.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>Hello All,</div><div><br></div><div>Our application operates on a dual-server setup, where each server is dedicated to running a distinct API.<br><b><br>Technical specifications:</b><br>Framework: Spring-boot v2.4 (Java 1.8)<br>Runtime Environment: Tomcat<br>Version: Apache Tomcat/7.0.42<br>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.<br><br><b>Issue Description:</b><br>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.<br><br></div><div>The Request Flow is as follows:</div><div><b style="background-color:rgb(255,255,0)">Browser --> Varnish on Server1 --> Tomcat on Server1 --> Varnish on Server2 --> Tomcat on Server2</b></div><div><b><br></b></div><div><b><i>Assuming, the request from Browser will be a miss at Server1 Varnish so that the request reaches Tomcat(Backend) on server1.</i></b><b><br></b><br>In cases where the browser <b><font color="#ff0000">does not include any cache-control headers</font> in the request</b> (e.g., no-cache, max-age=0), the Server1 Varnish instance correctly <b>does not receive any cache-control headers</b>.</div><div><br><b><font color="#000000">However, when API-1 calls API-2, we observe that a</font><font color="#ff0000"> cache-control: no-cache and p</font></b><b><font color="#ff0000">ragma: no-cache headers </font><font color="#000000">are being transmitted to the Varnish instance on Server2</font></b>, despite the following conditions:</div><div><br>1. We are not explicitly sending any cache-control header in our application code during the call from API-1 to API-2.<br>2. Our application does not use the Spring-security dependency, which by default might add such a header.<br>3. The cache-control header is not being set by the Varnish instance on Server2.</div><div><br><font color="#ff0000">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.</font></div><div><br>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.</div></div><div><br></div><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><font color="#000000">Thanks & Regards</font><div><font color="#000000">Uday Kumar</font></div></div></div></div></div>
_______________________________________________<br>
varnish-misc mailing list<br>
<a href="mailto:varnish-misc@varnish-cache.org" rel="noreferrer" target="_blank">varnish-misc@varnish-cache.org</a><br>
<a href="https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc" rel="noreferrer noreferrer" target="_blank">https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc</a><br>
</blockquote></div></div>
</blockquote></div>
</blockquote></div>