Entity Tag Candidate Match Indexes

Description

Return all entity-tag comparison candidate indexes under an explicit weak/strong rule, retaining ties and rejecting malformed tags; not If-Match/If-None-Match wildcard evaluation.

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.

Return all entity-tag comparison candidate indexes under an explicit weak/strong rule, retaining ties and rejecting malformed tags; not If-Match/If-None-Match wildcard evaluation.

When to use this tool

Use this tool to return all entity-tag comparison candidate indexes under an explicit weak/strong rule, retaining ties and rejecting malformed tags; not If-Match/If-None-Match wildcard evaluation.

How to use the tool and how it works

Enter candidateTags, target, weak using the input definitions below.
Run the operation. Resolve malformed-input errors before interpreting the result.
Read result.indexes. Interpret signs, units, ordering and null values using the rules below.

Parse the target and every candidate. Return original candidate indexes with equal opaque values, additionally requiring both tags to be strong when weak is false.^{[1, 2]}

Input field	Meaning and units	Accepted input
candidateTags	Complete candidate entity-tag tokens in original order.	Dense list of at most 128 strings, each at most 8,192 UTF-16 code units.
target	Complete target entity-tag token.	Text, at most 8,192 UTF-16 code units; the stated grammar and narrower limits also apply.
weak	True selects weak comparison; false requires both tags in each match to be strong.	Boolean true or false.

Output field	Interpretation
result	Object containing the fields below.
result.indexes	All matching original candidate-tag indexes.

json

{
  "input": {
    "candidateTags": [
      "W/\"a\"",
      "\"a\"",
      "\"b\""
    ],
    "target": "\"a\"",
    "weak": false
  },
  "output": {
    "result": {
      "indexes": [
        1
      ]
    }
  }
}

Limitations and assumptions

All malformed candidate tags reject the input, even if another candidate would match; wildcard request semantics are not implemented.
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

RFC 9110: Entity Tags and Comparison — RFC Editor
Tool behavior and example: Entity Tag Candidate Match Indexes — tool.io

Similar or alternative tools

Entity Tag Strong Record Match
Compare two explicitly parsed entity tags using RFC strong comparison; no wildcard conditional request or resource-state inference.
Entity Tag Weak Record Match
Compare two explicitly parsed entity tags using RFC weak comparison; no wildcard conditional request or resource-state inference.