Skip to content

Main content

HTTP Header Parameter Repeated Value Groups

Group repeated exact decoded HTTP parameter values by case-insensitive name plus case-sensitive value, reusing the existing parameter parser.

Loading tool…

Description

Group repeated exact decoded HTTP parameter values by case-insensitive name plus case-sensitive value, reusing the existing parameter parser.

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

Group repeated exact decoded HTTP parameter values by case-insensitive name plus case-sensitive value, reusing the existing parameter parser.

When to use this tool

Use this tool to group repeated exact decoded HTTP parameter values by case-insensitive name plus case-sensitive value, reusing the existing parameter parser.

How to use the tool and how it works

  1. Enter parameters using the field definitions below.
  2. Run the operation. Correct input errors before interpreting an output.
  3. Read result.groups. Use the ordering, boundary rules and absence conditions described below.

Parse semicolon-separated parameter assignments, normalize names and decoded values, then group repeated exact name/value pairs with occurrence indexes.2

Input fieldMeaning and unitsAccepted input
parametersSemicolon-separated name=value parameter text.Text, at most 8,192 UTF-16 code units; the operation’s grammar also applies.
Output fieldInterpretation
resultObject containing the named fields below.
result.groupsFirst-seen repeated parameter-value or normalized header-name occurrence groups.
json
{
  "input": {
    "parameters": "a=1;A=\"1\";a=2"
  },
  "output": {
    "result": {
      "groups": [
        {
          "key": "[\"a\",\"1\"]",
          "indexes": [
            0,
            1
          ]
        }
      ]
    }
  }
}

Limitations and assumptions

  • Different values under one name are not grouped together; parameter-specific conflict rules are not applied.
  • 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

  1. RFC 9110: HTTP Semantics — RFC Editor

  2. Tool behavior and example: HTTP Header Parameter Repeated Value Groups — tool.io

Similar or alternative tools

  • HTTP Header Occurrence Name Groups

    Group all HTTP field occurrences under ASCII case-insensitive names while retaining raw ordered occurrences; no list combination or deduplication.

  • HTTP Header Occurrence Value Redaction

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