In the implementing class of SimpleFeatureSource, request header content does not get updated

Question

In my project, I am using GeoServer 2.22.0 with a class that implements org.geotools.data.simple.SimpleFeatureSource, to wrap a normal JDBC feature source and to apply customized filters. In the implementation class, I rely on the correctness of the header content of the request that geoserver is processing. The problem I am seeing is that after the first request processed by geoserver, important header contents that should get updated are not updated as expected. It seems that geoserver is caching part of the request (at least the header content).

Here is a more detailed description of what I am doing and of the problem I am seeing.

In the implementation class, we override the following method:

@Override
public SimpleFeatureCollection getFeatures(Query query) throws IOException;

with these few lines:

public SimpleFeatureCollection getFeatures(Query query) throws IOException {
   Request request = Dispatcher.REQUEST.get();
   ...
   HttpServletRequest owsRequest = request.getHttpRequest();
   
   Enumeration<String> headerNames = owsRequest.getHeaderNames();
   
   // Step 1:  Output the header content of the request
   while (headerNames.hasMoreElements()) {
      String headerName = (String) headerNames.nextElement();
      // output the headerName and its value: owsRequest.getHeader(headerName)
      // Note that among the headers, there can be also "cookie".
   }

   // Step 2: there is also another way to access the cookies
   if (owsRequest.getCookies() != null ) {
      for (Cookie cookie: owsRequest.getCookies()) {
         // output the cookie content (cookie.getName() and cookie.getValue())
      }
   }
}

The 1st request can be sent via the curl command:

curl '<URL>' \
  -H 'authority: XXXXXX' \
  -H 'accept: application/json, text/plain, */*' \
  -H 'accept-language: en-US,en;q=0.9,fr;q=0.8' \
  -H 'content-type: application/x-www-form-urlencoded' \
  -H 'cookie: cookieName1=cookieValue1; cookieName2=cookieValue2; cookieName3=cookieValue3' \
  -H 'sec-ch-ua: "Google Chrome";v="119", "Chromium";v="119", "Not?A_Brand";v="24"' \
  -H 'sec-ch-ua-mobile: ?0' \
  -H 'sec-ch-ua-platform: "Windows"' \
  -H 'sec-fetch-dest: empty' \
  -H 'sec-fetch-mode: cors' \
  -H 'sec-fetch-site: same-origin' \
  -H 'user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36' \
  --data-raw $'service=WFS&request=GetFeature&srsname=EPSG:3857&outputFormat=application/json&efr=false&typeNames=xxxx&count=200&version=2.0.0&sortBy=yyy A&cql_filter=<someFilter>' \
  --compressed

In the curl command above, you can add your own extra header -H 'yourHeaderName: yourHeaderValue' for testing purpose.

A second request is sent via the curl command. Change the value of your own extra header.

What I am observing is that for subsequent requests, the header values never get updated. So with the example above, at the second request, your own extra header value is stuck at its very first value (the one from your first request).

Another weird behavior I am observing and that may be useful for the investigation. In the step 2 above, I mentioned about the call of owsRequest.getCookies(). Strangely enough, this method seems to return the right cookie (unlike owsRequest.getHeader('cookie')). But over time, owsRequest.getCookies() returns null, so there is no way to retrieve any cookie information either.