Okay thank you!
On Wed, Jun 28, 2023, 22:36 Guillaume Quintard
wrote:
> 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
>
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.
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
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
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