HTTP Status Code / Header Lookup mechanism

Model scope

The core status-code and header lookup concept is valid, but the specification needs review before implementation. Define the authoritative header registry, the exact header-output schema, validation and miss behavior, and label non-normative common-cause and related-code annotations as curated reference guidance.

• The lookup-only approach is appropriate; status-code class can be derived as floor(status_code/100) followed by 'xx' for valid three-digit codes.
• The requested 'common causes' and 'related codes' are not authoritative fields in the IANA registry and require clearly labeled editorial or operational data in addition to RFC-defined meanings.
• The specification does not define the header dataset or the output schema for header lookups, such as whether header category means request/response direction, field type, or semantics.

Units and conventions

• Status codes are unitless, three-digit decimal integers; standard HTTP status-code classes are 1xx through 5xx, normally 100-599.
• Header-name matching should be case-insensitive because HTTP field names are case-insensitive under RFC 9110.
• The bundled status table is assumed to use IANA HTTP Status Code Registry and RFC 9110 terminology; operational 'common causes' are not normative protocol values.
• The bundled header table is assumed to use RFC 9110 registered field semantics and should identify any extension or non-standard fields separately.

Inspectable vector

One of 4 source-bound review vectors:

{
  "inputs": {
    "status_code": 200
  },
  "expected_outputs": {
    "description": "OK",
    "category": "2xx",
    "common_causes": [
      "The request succeeded."
    ],
    "related_codes": [
      201,
      202,
      204
    ]
  },
  "reference_data": {
    "status_code_entry": {
      "code": 200,
      "description": "OK",
      "source_convention": "IANA HTTP Status Code Registry / RFC 9110 §15.3.1"
    },
    "category_rule": {
      "range": "200-299",
      "category": "2xx",
      "source_convention": "RFC 9110 status-code class convention"
    },
    "operational_annotation": {
      "common_causes": [
        "The request succeeded."
      ],
      "related_codes": [
        201,
        202,
        204
      ],
      "source_convention": "Widely tabulated standard operational interpretation; not an IANA normative field"
    }
  },
  "working": "1. Read status code 200 from the bundled registry. 2. Look up 200 => 'OK'. 3. Compute the class: floor(200 / 100) = 2, so the category is 2xx. 4. Return the bundled operational annotation: successful request; related success codes 201, 202, and 204."
}

Failure boundary

• Unknown, obsolete, deprecated, extension, and unofficial status codes must not be silently presented as standard IANA codes.
• Status codes outside 100-599, non-integer inputs, and integers with more or fewer than three decimal digits require explicit validation behavior; code 0 must not be treated as a valid HTTP status code.
• A lookup miss for a header must be distinguished from a recognized but deprecated or non-standard header.
• Header names must be matched case-insensitively, while header values and parameter names may have separate parsing rules.
• 'Common causes' can be misleading because the same status code or header can result from many application, proxy, cache, or server conditions.
• The empty honest_label is a concern: the panel should disclose that common causes and related-code lists are curated annotations, not always normative IANA or RFC fields.
• The data tables need an update/version policy because the IANA registry and HTTP field registry can change.

Other records

Sources and evidence

These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment.

• VERIFIED_LEDGER.json
• evidence-tranche7/tranche7-results.json