HTTP Status Code / Header Lookup implementation

Binding contract

This record describes what an executable surface must bind and validate. It does not claim that a public calculator, package, or production route is deployed.

Record owner

Guth Instruments

Lifecycle

verified-clean

Evidence ID

t7-038

Effect

Computation or source lookup only

Input and validation requirements

• 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.

Required corrections

No binding erratum is attached to this unique-name record. Implementers must still preserve the declared units, domain, and failure behavior.

Inspectable interface fixture

The sample below is evidence for interface and validation tests, not a production implementation.

{
  "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."
}

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