HTTP Header Occurrence Value Redaction

Description

Redact complete supplied HTTP field values by explicit case-insensitive names without modifying occurrence order; not a guarantee that sensitive data is absent elsewhere.

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]

Redact complete supplied HTTP field values by explicit case-insensitive names without modifying occurrence order; not a guarantee that sensitive data is absent elsewhere.

When to use this tool

Use this tool to redact complete supplied HTTP field values by explicit case-insensitive names without modifying occurrence order; not a guarantee that sensitive data is absent elsewhere.

How to use the tool and how it works

Enter headersJson, names, replacement using the field definitions below. For JSON text, serialize the explicit records in the shown shape.
Run the operation. Correct input errors before interpreting an output.
Read result.headers. Use the ordering, boundary rules and absence conditions described below.

Validate header records and replacement text, then replace values whose names match the supplied names case-insensitively, retaining names and order.^[2]

Input field	Meaning and units	Accepted input
headersJson	JSON text encoding array of {name: string, value: string}. Keep the record keys and value types shown in the decoded example below.	Text, at most 8,192 UTF-16 code units; the operation’s grammar also applies.
names	Header names to select or redact, matched case-insensitively.	Dense list of at most 128 strings, each at most 8,192 UTF-16 code units.
replacement	Single-byte-compatible replacement field value without CR or LF.	Text, at most 8,192 UTF-16 code units; the operation’s grammar also applies.

These are the decoded structures used in the example’s JSON text fields. Supply the corresponding serialized JSON strings as input.

json

{
  "headersJson": [
    {
      "name": "X-A",
      "value": "one"
    },
    {
      "name": "x-a",
      "value": "two"
    },
    {
      "name": "Set-Cookie",
      "value": "a=1"
    }
  ]
}

Output field	Interpretation
result	Object containing the named fields below.
result.headers	Selected, redacted or concatenated header occurrences, with indexes where stated.

json

{
  "input": {
    "headersJson": "[{\"name\":\"X-A\",\"value\":\"one\"},{\"name\":\"x-a\",\"value\":\"two\"},{\"name\":\"Set-Cookie\",\"value\":\"a=1\"}]",
    "names": [
      "x-a"
    ],
    "replacement": "[redacted]"
  },
  "output": {
    "result": {
      "headers": [
        {
          "name": "X-A",
          "value": "[redacted]"
        },
        {
          "name": "x-a",
          "value": "[redacted]"
        },
        {
          "name": "Set-Cookie",
          "value": "a=1"
        }
      ]
    }
  }
}

Limitations and assumptions

Only explicitly named fields are redacted; this does not discover credentials in other headers or payloads.
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 Header Occurrence Value Redaction — tool.io

Similar or alternative tools

HTTP Header Occurrence Byte Budget
Budget HTTP/1 field section octets under literal name-colon-space-value-CRLF serialization plus final CRLF; Latin-1 octets, not HTTP/2 compression or UTF-8.
HTTP Header Occurrence Case Collisions
Audit HTTP field-name spelling collisions separately from repeated identical spellings; validates token names and Latin-1 field-value octets.