HTTP Token Offer Intersection

Description

Intersect explicit HTTP token offers against a case-insensitive token bank or wildcard, preserving offer order and duplicates; no language/media subtype matching.

HTTP field names are case-insensitive, while values follow each field’s own grammar. Repeated occurrences sometimes form lists but cannot always be combined. Quoted values, optional spaces/tabs and quality weights need their own treatment; the tools here use explicit field records or a stated text subset.^[1]

Intersect explicit HTTP token offers against a case-insensitive token bank or wildcard, preserving offer order and duplicates; no language/media subtype matching.

When to use this tool

Use this tool to intersect explicit HTTP token offers against a case-insensitive token bank or wildcard, preserving offer order and duplicates; no language/media subtype matching.

How to use the tool and how it works

Enter requested, offers using the field definitions below.
Run the operation. Correct input errors before interpreting an output.
Read result.matches. Use the ordering, boundary rules and absence conditions described below.

Validate requested and offered tokens and return offers matching a requested token case-insensitively or a requested wildcard, preserving offer indexes.^[2]

Input field	Meaning and units	Accepted input
requested	Requested token strings, with a whole-token wildcard allowed.	Dense list of at most 128 strings, each at most 8,192 UTF-16 code units.
offers	Explicit offered token strings in original order.	Dense list of at most 128 strings, each at most 8,192 UTF-16 code units.

Output field	Interpretation
result	Object containing the named fields below.
result.matches	Matching offered tokens with their original offer indexes.

json

{
  "input": {
    "requested": [
      "A"
    ],
    "offers": [
      "a",
      "b",
      "A"
    ]
  },
  "output": {
    "result": {
      "matches": [
        {
          "index": 0,
          "offer": "a"
        },
        {
          "index": 2,
          "offer": "A"
        }
      ]
    }
  }
}

Limitations and assumptions

There are no quality weights or header-specific negotiation rules, and duplicate offers remain separate.
Explicit header records have name and value strings. Names must use token syntax; supported value code units are tab or 32–255 excluding DEL. Byte budgets use that single-byte representation, not UTF-8 or HTTP/2 compression.
Every declared top-level input field is required and unexpected 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 no larger in absolute magnitude than the safe-integer limit; operations returning exact large integers use decimal text. Positions are zero-based and spans end exclusively unless the operation explicitly states a different convention.

Alternative or Complementary methods

Choose field-specific parsing and combination rules rather than applying one policy to every header. Preserve occurrence order and use a full HTTP implementation for message framing and protocol-level decisions.

References

RFC 9110: HTTP Semantics — RFC Editor
Tool behavior and example: HTTP Token Offer Intersection — tool.io

Similar or alternative tools

HTTP Header Top-Level Comma Token Splitter
Split HTTP comma lists with the existing quote/escape-aware scanner, not generic parentheses or CSS syntax; trims outer whitespace and preserves quoted text.
HTTP Header Quoted Token Source Map
Map complete HTTP quoted-string source spans and decoded quoted-pair values; token contents are Latin-1/HTAB and unclosed escapes/strings reject.