Class FCHeaders

java.lang.Object
org.frontcache.core.FCHeaders
public class FCHeaders extends Object

  • Field Details

    • ACCEPT_ENCODING

      public static final String ACCEPT_ENCODING
      See Also:

    • ACCEPT

      public static final String ACCEPT
      See Also:

    • CONTENT_TYPE

      public static final String CONTENT_TYPE
      See Also:

    • CACHE_CONTROL

      public static final String CACHE_CONTROL
      See Also:

    • RETRY_AFTER

      public static final String RETRY_AFTER
      See Also:

    • PRAGMA

      public static final String PRAGMA
      See Also:

    • REQUEST_CLIENT_TYPE_BOT

      public static final String REQUEST_CLIENT_TYPE_BOT
      See Also:

    • REQUEST_CLIENT_TYPE_GUEST

      public static final String REQUEST_CLIENT_TYPE_GUEST
      See Also:

    • COMPONENT_REFRESH_TYPE_REGULAR

      public static final String COMPONENT_REFRESH_TYPE_REGULAR
      See Also:

    • COMPONENT_REFRESH_TYPE_SOFT

      public static final String COMPONENT_REFRESH_TYPE_SOFT
      See Also:

    • X_FRONTCACHE_ID

      public static final String X_FRONTCACHE_ID
      See Also:

    • X_FRONTCACHE_SITE_KEY

      @Deprecated public static final String X_FRONTCACHE_SITE_KEY
      Deprecated.
      send Authorization: Bearer <api-key> instead
      The pre-2.7 way to send the management API key. Nothing sends it any more - every Frontcache caller now uses Authorization: Bearer <api-key> - but nodes still ACCEPT it, because an embedded frontcache-agent, a separately deployed console or an older peer node may be older than the node it is calling. See ApiKey. Remove once every supported caller is 2.7 or later. The header name itself keeps "site-key": it is a fixed string on the wire that older callers send, so renaming it would simply stop accepting them, which is the whole reason it still exists.
      See Also:

    • X_FRONTCACHE_FALLBACK_IS_USED

      public static final String X_FRONTCACHE_FALLBACK_IS_USED
      See Also:

    • X_FRONTCACHE_DYNAMIC_REQUEST

      public static final String X_FRONTCACHE_DYNAMIC_REQUEST
      See Also:

    • X_FRONTCACHE_SOFT_REFRESH

      public static final String X_FRONTCACHE_SOFT_REFRESH
      See Also:

    • X_FRONTCACHE_ASYNC_INCLUDE

      public static final String X_FRONTCACHE_ASYNC_INCLUDE
      See Also:

    • X_FRONTCACHE_TRACE

      public static final String X_FRONTCACHE_TRACE
      See Also:

    • X_FRONTCACHE_TRACE_REQUEST

      public static final String X_FRONTCACHE_TRACE_REQUEST
      See Also:

    • X_FRONTCACHE_INCLUDE_LEVEL

      public static final String X_FRONTCACHE_INCLUDE_LEVEL
      See Also:

    • X_FRONTCACHE_COMPONENT

      public static final String X_FRONTCACHE_COMPONENT
      See Also:

    • COMPONENT_TOPLEVEL

      public static final String COMPONENT_TOPLEVEL
      See Also:

    • COMPONENT_INCLUDE

      public static final String COMPONENT_INCLUDE
      See Also:

    • COMPONENT_ASYNC_INCLUDE

      public static final String COMPONENT_ASYNC_INCLUDE
      See Also:

    • COMPONENT_COMBINED_INCLUDE

      public static final String COMPONENT_COMBINED_INCLUDE
      A sync include that was resolved as one member of a combined origin call (docs/archive/combine-reduce-proposal.md). Its own line in the trace headers carries the BATCH's elapsed time, not a time of its own - so N members of one batch report N identical durations that do not sum to the page time. This marker is what tells a reader of front-cache.log-to-headers why.
      See Also:

    • CACHE_LEVEL_L1

      public static final String CACHE_LEVEL_L1
      See Also:

    • CACHE_LEVEL_L2

      public static final String CACHE_LEVEL_L2
      See Also:

    • X_FRONTCACHE_COMPONENT_CACHE_LEVEL

      public static final String X_FRONTCACHE_COMPONENT_CACHE_LEVEL
      See Also:

    • X_FRONTCACHE_COMPONENT_MAX_AGE

      public static final String X_FRONTCACHE_COMPONENT_MAX_AGE
      See Also:

    • X_FRONTCACHE_COMPONENT_REFRESH_TYPE

      public static final String X_FRONTCACHE_COMPONENT_REFRESH_TYPE
      See Also:

    • X_FRONTCACHE_COMPONENT_TAGS

      public static final String X_FRONTCACHE_COMPONENT_TAGS
      See Also:

    • X_FRONTCACHE_REQUEST_ID

      public static final String X_FRONTCACHE_REQUEST_ID
      See Also:

    • X_FRONTCACHE_CLIENT_IP

      public static final String X_FRONTCACHE_CLIENT_IP
      See Also:

    • X_FRONTCACHE_CLIENT_TYPE

      public static final String X_FRONTCACHE_CLIENT_TYPE
      The client type (REQUEST_CLIENT_TYPE_BOT / REQUEST_CLIENT_TYPE_GUEST) the node serving the PAGE decided, carried to an <fc:include> fetch so the fragment is classified the same way as the page holding it. Without it, a re-entering include is classified on its own: the User-Agent survives the hop, so a UA-only bots.conf agrees by accident, but a client-ip: rule sees the sibling node's address and a cookie: rule may see no cookies at all (an async include is resolved after the servlet request is recycled). The page then reads one branch of a WebResponse's expireTimeMap and its fragments read the other, which shows up as fragments quietly no longer being cached. Honoured ONLY from a peer in front-cache.client-ip.trusted-proxies, and only on a request that arrived as an include. Same rule as X_FRONTCACHE_CLIENT_IP, and the same reason: FCUtils.isIncludedHeader forwards everything it does not blacklist, so without the check this would be a classify-yourself header. It is blacklisted there too, so a value a client sent is dropped rather than passed on.
      See Also:

    • X_FRONTCACHE_WARM

      public static final String X_FRONTCACHE_WARM
      The cache warmer's credential on a warm request - see org.frontcache.warmer.WarmRequest. Every header whose name starts with this one is dropped by FCUtils.isIncludedHeader, so none of them reaches the origin. That drop is load-bearing: the token in the origin app's access log would let whoever reads that log skip the guard rules and force refreshes.
      See Also:

    • X_FRONTCACHE_WARM_MODE

      public static final String X_FRONTCACHE_WARM_MODE
      fill | refresh - honoured only beside a valid X_FRONTCACHE_WARM.
      See Also:

    • X_FRONTCACHE_WARM_CLIENT_TYPE

      public static final String X_FRONTCACHE_WARM_CLIENT_TYPE
      bot | guest - honoured only beside a valid X_FRONTCACHE_WARM.
      See Also:

    • X_FRONTCACHE_WARM_RESULT

      public static final String X_FRONTCACHE_WARM_RESULT
      Response header on a warm request only: stored | fresh | not-cacheable | fallback. Without it the warmer sees a status code, and "200, stored" and "200, not cacheable" look the same.
      See Also:

    • X_FRONTCACHE_WARM_KEY

      public static final String X_FRONTCACHE_WARM_KEY
      Response header on a warm request only: the cache key the node built for it. The warmer compares it with its key base, because the key's scheme comes from the container's view of X-Forwarded-Proto and a container that ignores that header would otherwise have the run store every entry under a key no visitor's request produces - and report them stored.
      See Also:

    • X_FORWARDED_PROTO

      public static final String X_FORWARDED_PROTO
      See Also:

    • X_FORWARDED_HOST

      public static final String X_FORWARDED_HOST
      See Also:

    • COMPONENT_TAGS_SEPARATOR

      public static final String COMPONENT_TAGS_SEPARATOR
      See Also:

  • Constructor Details

    • FCHeaders

      public FCHeaders()