Entity Tag Strong Record Match

Description

Compare two explicitly parsed entity tags using RFC strong comparison; no wildcard conditional request or resource-state inference.

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.

Compare two explicitly parsed entity tags using RFC strong comparison; no wildcard conditional request or resource-state inference.

When to use this tool

Use this tool to compare two explicitly parsed entity tags using RFC strong comparison; no wildcard conditional request or resource-state inference.

How to use the tool and how it works

Enter left, right using the input definitions below.
Run the operation. Resolve malformed-input errors before interpreting the result.
Read result.matches. Interpret signs, units, ordering and null values using the rules below.

Parse both complete entity tags. Match only when opaque values are equal and neither tag has a weak prefix.^{[1, 2]}

Input field	Meaning and units	Accepted input
left	One complete entity tag, optionally beginning W/, with its quoted opaque value.	Text, at most 8,192 UTF-16 code units; the stated grammar and narrower limits also apply.
right	Second complete entity tag in the same grammar.	Text, at most 8,192 UTF-16 code units; the stated grammar and narrower limits also apply.

Output field	Interpretation
result	Object containing the fields below.
result.matches	Whether the selected weak/strong entity-tag comparison succeeds.

json

{
  "input": {
    "left": "W/\"a\"",
    "right": "\"a\""
  },
  "output": {
    "result": {
      "matches": false
    }
  }
}

Limitations and assumptions

This is strong tag comparison only; equal tag strings do not independently establish server state.
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 Strong Record Match — tool.io

Similar or alternative tools

Entity Tag Candidate Match Indexes
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.
Entity Tag Weak Record Match
Compare two explicitly parsed entity tags using RFC weak comparison; no wildcard conditional request or resource-state inference.