Re: Unexpected Cache-Control Header Transmission in Dual-Server API Setup
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
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
*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
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
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
*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
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
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
