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

2023-06-30 Thread Uday Kumar
Okay Thanks 

On Sat, Jul 1, 2023, 00:42 Christopher Schultz 
wrote:

> Uday,
>
> On 6/30/23 06:57, Uday Kumar wrote:
> > *Hello,*
> >
> > *Observations:*
> > *1. Issue not replicated through integrated tomcat of Spring-boot when
> the
> > application was started in IntelliJ IDE*
> > *2. Issue was replicated by installing Tomcat 9 on my local machine and
> > building the corresponding war file.*
> >
> > *In both the above cases, I use the same code and the same HTTP Client (*
> > *java.net.HttpURLConnection**) for calling other API which is on another
> > server.*
> >
> > *I even tried using **org.springframework.web.client.RestTemplate *client
> > for calling other API, but the same observations were seen as mentioned
> > above.
>
> I'm not sure what else to tell you. When your code makes outgoing HTTP
> connections, no Tomcat code is involved *at all*. Tomcat does not change
> any JVM-wide settings. Tomcat does not intercept any outgoing
> connections for observation, modification, or adulteration.
>
> You should attach a debugger to your process to determine where the
> Cache-Control header is being added.
>
> It is not being added by Tomcat.
>
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


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

2023-06-30 Thread Christopher Schultz

Uday,

On 6/30/23 06:57, Uday Kumar wrote:

*Hello,*

*Observations:*
*1. Issue not replicated through integrated tomcat of Spring-boot when the
application was started in IntelliJ IDE*
*2. Issue was replicated by installing Tomcat 9 on my local machine and
building the corresponding war file.*

*In both the above cases, I use the same code and the same HTTP Client (*
*java.net.HttpURLConnection**) for calling other API which is on another
server.*

*I even tried using **org.springframework.web.client.RestTemplate *client
for calling other API, but the same observations were seen as mentioned
above.


I'm not sure what else to tell you. When your code makes outgoing HTTP 
connections, no Tomcat code is involved *at all*. Tomcat does not change 
any JVM-wide settings. Tomcat does not intercept any outgoing 
connections for observation, modification, or adulteration.


You should attach a debugger to your process to determine where the 
Cache-Control header is being added.


It is not being added by Tomcat.

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



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

2023-06-30 Thread Uday Kumar
*Hello,*

*Observations:*
*1. Issue not replicated through integrated tomcat of Spring-boot when the
application was started in IntelliJ IDE*
*2. Issue was replicated by installing Tomcat 9 on my local machine and
building the corresponding war file.*

*In both the above cases, I use the same code and the same HTTP Client (*
*java.net.HttpURLConnection**) for calling other API which is on another
server.*

*I even tried using **org.springframework.web.client.RestTemplate *client
for calling other API, but the same observations were seen as mentioned
above.

"Tomcat is not an HTTP client and provides no HTTP client API. You need
> to look at whatever code is issuing the request from Tomcat on Server1
> to Varnish on Server2. The one thing I can be certain of is that no
> Tomcat code is involved. "
>


Thanks & Regards,
Uday Kumar


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

2023-06-28 Thread Mark Thomas

On 28/06/2023 16:49, Uday Kumar wrote:

Hello Mark,

In continuation of my previous mail,
*Just in a while, I could replicate the issue on my local machine by
installing Tomcat 9 explicitly [Now, I could see cache-control headers are
being transmitted to Varnish of server2]*

*Point to note here,*
*Issue not replicated through integrated tomcat of Spring-boot*
*Issue replicated by installing Tomcat 9 on my local machine and building
corresponding war files.*

*I suspect, there is the configuration of Tomcat which is responsible for
setting Cache-control and pragma header by default to outgoing requests.*


This is absolutely, categorically NOT the case. Tomcat has NOTHING to do 
with outgoing HTTP requests. This is an issue with your configuration of 
whatever HTTP client llibrary you are using to make these requests.


*Kindly check and let me know if I am missing anything.*


This part of my previous reply:

"Tomcat is not an HTTP client and provides no HTTP client API. You need 
to look at whatever code is issuing the request from Tomcat on Server1 
to Varnish on Server2. The one thing I can be certain of is that no 
Tomcat code is involved. "


Mark




We have tried replicating the issue by using a local machine (spring-boot

application as an API-1 with integrated tomcat) to hit API-2 which is on
Server2, in this case, Cache-Control headers are *not being transmitted*
to Varnish of server2.



Thanks & Regards,
Uday Kumar



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



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

2023-06-28 Thread Uday Kumar
Hello Mark,

In continuation of my previous mail,
*Just in a while, I could replicate the issue on my local machine by
installing Tomcat 9 explicitly [Now, I could see cache-control headers are
being transmitted to Varnish of server2]*

*Point to note here,*
*Issue not replicated through integrated tomcat of Spring-boot*
*Issue replicated by installing Tomcat 9 on my local machine and building
corresponding war files.*

*I suspect, there is the configuration of Tomcat which is responsible for
setting Cache-control and pragma header by default to outgoing requests.*

*Kindly check and let me know if I am missing anything.*

We have tried replicating the issue by using a local machine (spring-boot
> application as an API-1 with integrated tomcat) to hit API-2 which is on
> Server2, in this case, Cache-Control headers are *not being transmitted*
> to Varnish of server2.
>

Thanks & Regards,
Uday Kumar


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

2023-06-28 Thread Uday Kumar
*Hi Mark,*

*You need to upgrade.*
*Noted!*


Will there be any default cache-control headers that are set (when they are
not set explicitly by API-1) by Tomcat when issuing a request from Tomcat
on Server1 to Varnish on Server2?

*You need to look at whatever code is issuing the request from Tomcat on
Server1 to Varnish on Server2*
We have tried replicating the issue by using a local machine (spring-boot
application as an API-1 with integrated tomcat) to hit API-2 which is on
Server2, in this case, Cache-Control headers are *not being transmitted* to
Varnish of server2.

Tomcat is not an HTTP client and provides no HTTP client API. You need
> to look at whatever code is issuing the request from Tomcat on Server1
> to Varnish on Server2. The one thing I can be certain of is that no
> Tomcat code is involved.
>

Thanks & Regards,
Uday Kumar


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

2023-06-28 Thread Mark Thomas

On 28/06/2023 14:23, Uday Kumar 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


Tomcat 7 reached End Of Life on 31 March 2021 - more than two years ago

https://tomcat.apache.org/tomcat-70-eol.html

You need to upgrade.



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.


Tomcat is not an HTTP client and provides no HTTP client API. You need 
to look at whatever code is issuing the request from Tomcat on Server1 
to Varnish on Server2. The one thing I can be certain of is that no 
Tomcat code is involved.


Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



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

2023-06-28 Thread Uday Kumar
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