Skip to content

Main content

Cache Directive Presence Policy

Report conservative presence flags for explicit cache directives and public/private conflict, not a complete cacheability decision; no-cache does not mean no-store.

Loading tool…

Description

Report conservative presence flags for explicit cache directives and public/private conflict, not a complete cacheability decision; no-cache does not mean no-store.

HTTP caches distinguish storage policy, freshness and validation. Age and freshness lifetime are durations in seconds; an entity tag is an opaque validator that can be marked weak. Vary identifies request fields relevant to representation selection. A focused arithmetic or token check alone does not decide whether a stored response may be reused.

Report conservative presence flags for explicit cache directives and public/private conflict, not a complete cacheability decision; no-cache does not mean no-store.

When to use this tool

Use this tool to report conservative presence flags for explicit cache directives and public/private conflict, not a complete cacheability decision; no-cache does not mean no-store.

How to use the tool and how it works

  1. Enter directivesJson using the input definitions below. Serialize the JSON text fields in the decoded shape shown below.
  2. Run the operation. Resolve malformed-input errors before interpreting the result.
  3. Read result.noStore, result.requiresValidation, result.private, result.public, result.publicPrivateConflict. Interpret signs, units, ordering and null values using the rules below.

Normalize explicit directive names to lowercase. Return presence flags for no-store, no-cache, private and public, plus publicPrivateConflict when both visibility directives occur.1, 2

Input fieldMeaning and unitsAccepted input
directivesJsonJSON array of {name,value} directives: HTTP token name and a string value or null for a bare directive. Names are normalized to lowercase.Text, at most 8,192 UTF-16 code units; the stated grammar and narrower limits also apply.

These decoded examples show the structure of the JSON text fields. Supply each as its corresponding serialized JSON string.

json
{
  "directivesJson": [
    {
      "name": "no-cache",
      "value": null
    },
    {
      "name": "public",
      "value": null
    }
  ]
}
Output fieldInterpretation
resultObject containing the fields below.
result.noStoreWhether a no-store directive occurs.
result.requiresValidationWhether a no-cache directive occurs.
result.privateWhether a private directive occurs.
result.publicWhether a public directive occurs.
result.publicPrivateConflictWhether both public and private directives occur.
json
{
  "input": {
    "directivesJson": "[{\"name\":\"no-cache\",\"value\":null},{\"name\":\"public\",\"value\":null}]"
  },
  "output": {
    "result": {
      "noStore": false,
      "requiresValidation": true,
      "private": false,
      "public": true,
      "publicPrivateConflict": false
    }
  }
}

Limitations and assumptions

  • no-cache means validation is required under its applicable semantics, not that storage is forbidden. Flags alone are not a complete request/response cacheability decision.
  • No HTTP exchange, cache store, clock or server is accessed. Header/directive occurrences and timestamps are supplied explicitly. Durations use seconds for HTTP semantics; timestamps must share an origin and unit.
  • Every declared top-level input is required and unknown fields are rejected. Ordinary strings are limited to 8,192 UTF-16 code units and lists to 128 entries, with tighter operation-specific bounds where stated. JSON text has bounded nesting and node counts.
  • Numeric outputs must be finite and within the absolute safe-integer magnitude; exact larger integers use decimal text. Source positions are zero-based UTF-16 offsets and span ends are exclusive unless a different convention is explicitly stated.

Alternative or Complementary methods

Combine these focused results with the request/response caching rules applicable to the actual exchange. Preserve field occurrences and distinguish freshness calculations, validator comparison and complete cache-reuse authorization.

References

  1. RFC 9111: HTTP Caching — RFC Editor

  2. Tool behavior and example: Cache Directive Presence Policy — tool.io

Similar or alternative tools

  • Cache Directive Extension Inventory

    Inventory explicit cache directive names outside a caller-provided known-name bank; no hardcoded current registry or automatic extension semantics.

  • Cache Directive Numeric Value Audit

    Audit unsigned decimal syntax of caller-declared numeric cache directives without coercing or accepting signs, quotes or defaults; values remain raw strings.