Check Every Authorization Field Before Python Authentication

Two owned header lines are enough to expose the review problem:

Authorization: Bearer owned-A
Authorization: Bearer owned-B

A convenient single-value lookup can return a perfectly plausible string from that parsed message. That observation does not establish that exactly one Authorization field was present. For a receiving API that intends to admit only one Bearer-shaped credential to its authentication layer, the first question therefore is not “does get() give me a token-looking value?” It is “how many Authorization values does this representation retain?”

The policy examined here is deliberately narrow: reject a missing Authorization field, reject more than one retained Authorization occurrence, reject a single value that does not match the selected whole-value Bearer shape, and classify one structurally eligible value as ADMIT_TO_AUTHENTICATOR. That last label is a handoff decision, not an authentication result.

The experiment uses CPython’s standard library, literal ASCII header-line blocks in io.BytesIO, and http.client.parse_headers. Python documents that parse_headers() consumes header field lines, returns an HTTPMessage, leaves the file pointer positioned for the body, and does not parse an HTTP start-line. The maintained Python 3.12 documentation viewed for this article displays 3.12.16; the commissioning execution described below used CPython 3.12.14.

No server, network connection, identity provider, genuine credential, JWT validation, or authorization decision is involved. The objective is evidence about a parsed representation and a bounded pre-authentication admission policy.

Define the Authorization admission decision

Start with the endpoint policy, not with whichever accessor is easiest to call.

For this laboratory, the receiving adapter applies four mutually exclusive decisions:

These are application classifications chosen for this article. They are not HTTP status codes selected by Python, and they do not imply what error envelope a production API should return.

The distinction matters because two owners are involved. The receiving adapter can establish facts about the representation it has: whether the field is missing, whether multiple named occurrences remain visible, and whether one retained string matches the bounded syntax expected by this endpoint. A separately implemented authenticator must determine whether that credential is issued, current, acceptable for the intended audience, or otherwise valid under the real authentication system. Endpoint authorization remains later still.

That is a different problem from identifying which credential source an outgoing client ultimately sent. Refonte’s article on outgoing Requests credential-source checks examines that client-side boundary; the present workflow begins after a receiving representation exists.

RFC 9110 defines the Authorization field as carrying credentials used by a user agent to authenticate itself to an origin server. It does not say that a convenient mapping lookup is sufficient evidence for an application’s field-count policy.

The operational rule is consequently explicit: do not select a credential until the adapter has established that exactly one relevant field value is present in the representation being reviewed.

Understand what the parsed header object retains

An HTTPMessage resembles a mapping closely enough that a reviewer can accidentally bring ordinary dictionary expectations to it. Python’s documentation is more specific. http.client.HTTPMessage is implemented using email.message.Message, and the latter models an ordered collection of header fields in which duplicate headers are supported. Header names are matched case-insensitively.

That representation gives the adapter an important opportunity: it can inspect all retained values for a field before choosing one.

Python documents two access patterns with materially different evidentiary value. get(name) has the same single-value behavior as the item accessor. If a named field occurs more than once, the documentation expressly says which field value is returned is undefined. get_all(name, failobj) returns a list containing all values for that named field.

For a policy whose question is “exactly one Authorization occurrence?”, get_all("Authorization", []) therefore supplies the relevant retained-list evidence. A value returned by get() can still be useful as an observation, but it cannot by itself prove the required cardinality.

This is a field-specific rule. HTTP does not establish a universal prohibition on repeated field lines. RFC 9110 makes repetition and combination dependent on the field’s definition, and it allows combination into comma-separated form only where the field’s semantics permit such recombination.

That distinction is similar in review discipline, but not implementation, to checking response-header multiplicity in NGINX: define the field-specific contract first, then inspect the representation that actually exists at that boundary. The NGINX article concerns response behavior; this experiment concerns a Python receiving object.

Separate named field occurrences from comma-separated text

Cases H02 and H08 intentionally look similar to a human reader while presenting different object shapes.

H02 authors two field lines:

Authorization: Bearer owned-A
Authorization: Bearer owned-B

Its expected all-values list contains two strings. Under the selected policy, that is an immediate multiplicity rejection.

H08 authors one field line:

Authorization: Bearer owned-A, Bearer owned-B

Its expected list contains one string. Cardinality therefore passes, but the complete retained string fails the chosen Bearer shape check.

The fixture does not claim an intermediary transformed H02 into H08. H08 was authored as one line. The useful point is narrower: “one retained field value” and “one syntactically eligible Bearer credential” are separate claims.

Freeze the parser boundary and authored expectations

The input corpus begins directly with header field lines. Each case appends a blank line and then owned-body-bytes\n. There is deliberately no method, request target, HTTP version, socket, or server object.

That shape matches the documented contract of http.client.parse_headers(): it expects a binary reader positioned at the field lines, returns an HTTPMessage, and leaves the input ready for the body. It does not parse the start-line.

Keeping the test cases as literal byte strings is important for this question. Constructing an ordinary dictionary such as {"Authorization": "Bearer owned-A"} would already have chosen a single value and could not represent two same-named occurrences independently. The laboratory needs the multiplicity to reach the parser.

Each case tuple contains three independently authored expectations: raw field bytes, the expected complete Authorization-value list, and the expected classification. The code does not derive that expected list from get(), nor does it derive the expected decision from observed parser output. That separation makes the fixture a test rather than a report generator that merely restates its own observations.

The recorded commissioning run used CPython 3.12.14 on Linux-6.18.57-x86_64-with-glibc2.39. The Python documentation researched on 2026-11-03 displays 3.12.16, so the documentation version and execution version should not be silently conflated. The documentation page also records an October 26, 2026 update timestamp.

The body sentinel is a local parse-boundary control: after parse_headers() returns, the fixture requires the remaining bytes to equal BODY. The empty message.defects lists are another corpus-specific control. Neither result establishes comprehensive HTTP validity.

To reproduce the laboratory, save the complete source below as security_http_headers_fixture.py in a writable directory. It uses only the Python standard library. Run the interpreter whose version you intend to report, capture standard output and standard error separately, and retain the process exit status. A run under a different interpreter is a new observation to reconcile, not a substitute for the recorded CPython 3.12.14 baseline.

Run the complete ten-case header experiment

The following source is the complete bounded fixture. It creates a fresh in-memory byte stream for each case, parses the header block, retrieves every retained Authorization value, separately observes the single-value accessor, classifies the message, checks the body sentinel and defects list, and finally prints a report only after every required assertion succeeds.

"""Owned, in-memory header-shape experiment; no server or authenticator."""
import hashlib
import http.client
import io
import json
import platform
import re
from datetime import datetime, timezone
from pathlib import Path

BODY = b"owned-body-bytes\n"
BEARER = re.compile(r"(?i:Bearer) +[A-Za-z0-9._~+/-]+=*")
CASES = [
    ("H01", b"Authorization: Bearer owned-A\r\n", ["Bearer owned-A"],
     "ADMIT_TO_AUTHENTICATOR"),
    ("H02", b"Authorization: Bearer owned-A\r\nAuthorization: Bearer owned-B\r\n",
     ["Bearer owned-A", "Bearer owned-B"], "REJECT_MULTIPLE_AUTHORIZATION"),
    ("H03", b"Authorization: Bearer owned-B\r\nAuthorization: Bearer owned-A\r\n",
     ["Bearer owned-B", "Bearer owned-A"], "REJECT_MULTIPLE_AUTHORIZATION"),
    ("H04", b"Authorization: Bearer owned-A\r\nAuthorization: Bearer owned-A\r\n",
     ["Bearer owned-A", "Bearer owned-A"], "REJECT_MULTIPLE_AUTHORIZATION"),
    ("H05", b"X-Lab: missing-authorization\r\n", [], "REJECT_MISSING_AUTHORIZATION"),
    ("H06", b"Authorization:\r\n", [""], "REJECT_CREDENTIAL_SHAPE"),
    ("H07", b"Authorization: Bearer owned-A\r\nauthorization: Bearer owned-B\r\n",
     ["Bearer owned-A", "Bearer owned-B"], "REJECT_MULTIPLE_AUTHORIZATION"),
    ("H08", b"Authorization: Bearer owned-A, Bearer owned-B\r\n",
     ["Bearer owned-A, Bearer owned-B"], "REJECT_CREDENTIAL_SHAPE"),
    ("H09", b"authorization: bearer owned-A\r\n", ["bearer owned-A"],
     "ADMIT_TO_AUTHENTICATOR"),
    ("H10", b"Authorization: Bearer owned-B\r\n", ["Bearer owned-B"],
     "ADMIT_TO_AUTHENTICATOR"),
]


def classify_shape(message):
    values = message.get_all("Authorization", [])
    if not values:
        return "REJECT_MISSING_AUTHORIZATION"
    if len(values) != 1:
        return "REJECT_MULTIPLE_AUTHORIZATION"
    if BEARER.fullmatch(values[0]) is None:
        return "REJECT_CREDENTIAL_SHAPE"
    return "ADMIT_TO_AUTHENTICATOR"


def require(condition, label):
    if not condition:
        raise RuntimeError(label)


def main():
    rows = []
    for case_id, field_lines, expected_values, expected_decision in CASES:
        stream = io.BytesIO(field_lines + b"\r\n" + BODY)
        message = http.client.parse_headers(stream)
        values = message.get_all("Authorization", [])
        selected = message.get("Authorization")
        decision = classify_shape(message)
        remaining = stream.read()
        defects = [type(defect).__name__ for defect in message.defects]
        require(type(message) is http.client.HTTPMessage, case_id + ": message type")
        require(values == expected_values, case_id + ": all values")
        require(decision == expected_decision, case_id + ": shape decision")
        require(remaining == BODY and not defects, case_id + ": parse boundary")
        require(selected in values if values else selected is None,
                case_id + ": single accessor membership")
        rows.append({
            "case": case_id,
            "field_lines": field_lines.decode("ascii"),
            "expected_values": expected_values,
            "observed_values": values,
            "get_observed": selected,
            "expected_decision": expected_decision,
            "observed_decision": decision,
            "body_unchanged": remaining == BODY,
            "parser_defects": defects,
            "pass": True,
        })
    require(len(rows) == 10 and len({r["case"] for r in rows}) == 10, "case inventory")
    print(json.dumps({
        "status": "PASS_10_CASES",
        "executed_utc": datetime.now(timezone.utc).isoformat(),
        "python": platform.python_version(),
        "implementation": platform.python_implementation(),
        "platform": platform.platform(),
        "source_sha256": hashlib.sha256(Path(__file__).read_bytes()).hexdigest(),
        "authentication_performed": False,
        "network_used": False,
        "get_selection_contract": "Undefined for duplicate fields; reported as observation only.",
        "cases": rows,
    }, indent=2))


if name == "__main__":
    main()

Run it with the actual Python executable whose version will accompany the evidence:

python3 security_http_headers_fixture.py > security_http_headers_results.json 2> security_http_headers_stderr.txt

For each case, io.BytesIO contains exactly that case’s authored field lines, the terminating blank line, and the inert body sentinel. parse_headers() operates on that fresh buffer. The fixture then calls get_all("Authorization", []) for complete retained-list evidence and get("Authorization") only to record what the single accessor happened to choose. Python documents get_all() as returning all values for the named field and documents duplicate single-value selection as undefined.

classify_shape() deliberately evaluates cardinality before grammar. Zero values return REJECT_MISSING_AUTHORIZATION; any count other than one returns REJECT_MULTIPLE_AUTHORIZATION; only a single retained value reaches BEARER.fullmatch().

Python documents Pattern.fullmatch() as succeeding only when the whole string matches the regular expression and returning None otherwise. This is important for H08: a valid-looking Bearer prefix is not enough when additional comma-separated text remains in the value.

The commissioning record supplied with this article reports execution at 2026-11-03T07:52:32.530181+00:00, CPython 3.12.14, Linux 6.18.57-x86_64-with-glibc2.39, exit code zero, and report status PASS_10_CASES. It records source SHA-256 2e1f3c5a0ab1cd422fe6ec6415f3d418afca41ae7e01a48c58c83fbc4bbad07d. That digest identifies source bytes; it is not a signature, an execution attestation, or evidence about a deployed service.

The same record states network_used: false and authentication_performed: false. Those fields accurately describe the fixture’s source-level scope: there is no hidden network client, listening server, token verifier, or protected business operation behind ADMIT_TO_AUTHENTICATOR.

The script accumulates a row only after the case’s requirements pass. It prints the complete JSON report after the case inventory check. Consequently, redirected output alone is not evidence of success. Retain the process exit status, inspect stderr, and require the complete expected report. A nonzero exit, missing JSON, empty JSON, or partial case population is incomplete evidence.

Compare single-value access with the full field list

The duplicate cases make the difference between get() and get_all() concrete without requiring any malicious token.

In the recorded CPython 3.12.14 run, H02 authored A and then B. get("Authorization") observed Bearer owned-A, while get_all("Authorization", []) retained both values in the expected list: ["Bearer owned-A", "Bearer owned-B"].

H03 reversed the authored order. The single accessor observed Bearer owned-B, while the all-values list was ["Bearer owned-B", "Bearer owned-A"]. Both cases produced REJECT_MULTIPLE_AUTHORIZATION.

Those observations are useful evidence about that run, but they are not the API contract on which the repair should depend. Python’s documented contract is explicit: when a field appears more than once, exactly which value the item accessor returns is undefined; callers requiring all values should use get_all().

That is why the fixture’s single-accessor assertion is intentionally weak:

require(selected in values if values else selected is None,
        case_id + ": single accessor membership")

It verifies that an observed duplicate selection is one of the exposed values, but it does not require first-value selection. The actual admission decision never depends on which duplicate get() chooses.

For a security review, the problem with a lone message.get("Authorization") is therefore evidentiary. A plausible returned credential does not answer the policy question “was exactly one named field retained?” The string itself need not be malicious for that review to be incomplete.

Treat first-value selection as an observation

The CPython 3.12.14 commissioning run happened to return the first retained value in H02 and H03. The correct statement is version-qualified: that run observed first-value selection in those duplicate cases.

The incorrect statement would be “Python always takes the first Authorization header.”

If another conforming implementation or later version changed the duplicate selection returned by get() while preserving the documented all-values behavior, the fixture’s policy decision should remain unchanged. The comparison report should record the changed observation rather than rewriting the expected get_all() list or changing the cardinality policy to preserve a historical implementation detail.

This separation is exactly what makes the test useful across versions: field inventory is the evidence used for admission; single-value selection is ancillary evidence about the runtime.

Reject repeated fields before selecting a credential

H02, H03, H04, and H07 exercise four forms of the same policy condition.

H02 retains A followed by B. H03 retains B followed by A. Reordering does not change the outcome because the rule is based on count, not preference: each contains two Authorization values and therefore returns REJECT_MULTIPLE_AUTHORIZATION.

H04 is more revealing because both retained strings are identical:

Authorization: Bearer owned-A
Authorization: Bearer owned-A

The policy still rejects the message. The contract is “exactly one occurrence,” not “exactly one distinct credential string.” Replacing the list with set(values) before counting would silently create a different rule in which two equal occurrences collapse to one distinct value.

That might be a legitimate policy in some independently reviewed system, but it is not this one. The fixture treats multiplicity as a fact about the receiving representation, not as a token-comparison problem.

The same logic rules out “pick the first,” “pick the last,” and “pick whichever looks most valid.” Each strategy would select a credential before satisfying the declared cardinality requirement. Once the application has decided that repeated Authorization fields are not eligible for this endpoint, choosing a winner is no longer a neutral parser operation; it is a different admission policy.

RFC 9110 cautions against generalized assumptions about repeated fields. Its field-order rules say same-named lines are only generally recombinable where the field definition allows that list form; repetition is therefore field-specific rather than a universal normalize-first rule.

Nothing in H02–H04 proves exploitation. The evidence establishes only that multiple retained occurrences existed and that the selected application rule rejected them.

Count identical values and mixed-case names

H07 authors the names with different capitalization:

Authorization: Bearer owned-A
authorization: Bearer owned-B

Its expected all-values list still contains two entries. That matches Python’s Message contract: header names are matched case-insensitively. RFC 9110 likewise specifies HTTP field names as case-insensitive.

The repair is not to lowercase the credential value. Field-name comparison and credential contents are separate concerns.

H09 provides that control explicitly. Its field name is lowercase, and its authentication scheme is lowercase bearer, yet its owned token remains owned-A. The regex makes only the Bearer scheme portion case-insensitive. That is consistent with HTTP authentication-scheme matching, which RFC 9110 defines case-insensitively.

Check Bearer syntax after the cardinality decision

Once get_all() establishes exactly one retained Authorization value, the adapter still has not established that the value has the shape this endpoint intends to pass onward.

RFC 6750 section 2.1 defines Bearer credentials as the Bearer scheme, one or more spaces, and a b64token whose character repertoire includes letters, digits, -, ., _, ~, +, and /, with optional trailing equals signs.

The laboratory encodes that bounded shape as:

BEARER = re.compile(r"(?i:Bearer) +[A-Za-z0-9._~+/-]+=*")

The inline case-insensitive group applies only to Bearer. The token portion is not case-folded or decoded. fullmatch() requires the complete retained string to fit the expression rather than accepting a matching prefix. Python’s re documentation explicitly defines fullmatch() in whole-string terms.

That is syntax recognition, not token validation. The expression does not verify issuance, signature, expiration, audience, subject, scopes, permissions, revocation, or any other real authentication property. No cryptographic library or identity provider appears in the fixture.

H05 and H06 also show why cardinality should remain explicit.

H05 contains no Authorization field. get_all("Authorization", []) produces the expected empty list, and the decision is REJECT_MISSING_AUTHORIZATION.

H06 contains one empty field:

Authorization:

Its expected list is [""], so it is not classified as missing. It proceeds to the shape test and becomes REJECT_CREDENTIAL_SHAPE.

A truthiness test on a selected string could blur those categories. The all-values policy preserves the difference between no retained occurrence and one retained occurrence whose value is empty.

The regex remains intentionally small. It is not a general-purpose HTTP sanitation layer, an implementation of every authentication scheme, or a substitute for testing the actual receiving stack.

Test the one-field comma case

H08 is the counterexample to relying on count alone:

Authorization: Bearer owned-A, Bearer owned-B

get_all() is expected to return a list of length one because the fixture authored one field line with one complete value. That satisfies the cardinality condition.

It does not satisfy the Bearer expression. After Bearer owned-A, the comma and second Bearer string leave extra text that prevents fullmatch() from matching the entire value. The result is therefore REJECT_CREDENTIAL_SHAPE.

Splitting that value on commas and selecting one fragment would introduce new interpretation logic that the endpoint policy never declared. The fixture instead evaluates the whole retained value it was given.

RFC 9110’s general field-combination rules are precisely why this should not be generalized into “commas are invalid in HTTP authentication.” Field definitions govern list behavior, and other authentication schemes can have parameter syntax different from this bounded Bearer profile.

H08 proves only that this authored one-value string fails this selected Bearer shape.

Keep authentication beyond the shape boundary

H01, H09, and H10 all reach ADMIT_TO_AUTHENTICATOR.

H01 contains one Authorization: Bearer owned-A. H09 contains lowercase authorization: bearer owned-A. H10 contains one Authorization: Bearer owned-B. Each has exactly one retained value and each value satisfies the fixture’s whole-value expression.

That is as far as the evidence goes.

owned-A and owned-B are synthetic strings. Neither is established as an issued credential, and the fact that both pass the regex demonstrates why structural eligibility must not be renamed authentication. The commissioning report explicitly records authentication_performed: false.

A real receiving path would next hand the structurally eligible credential to a separately owned authenticator implementing the system’s actual token rules. Only that stage could establish an authenticated principal under its contract. Endpoint authorization would then determine whether that principal may perform the requested operation.

The adapter may also decide how to expose the three rejection categories through its normal API error model, but this fixture emits no HTTP response and supplies no status-code policy.

Naming is therefore part of the control. ADMIT_TO_AUTHENTICATOR says exactly what happened: the local representation passed the pre-authentication field-count and shape checks and is eligible for a later handoff. It must not be rewritten as AUTHENTICATED, ACCEPT_REQUEST, AUTHORIZED, or permission to perform protected behavior.

RFC 6750 describes how bearer tokens are presented in requests, but grammar alone does not establish that an arbitrary token-shaped string is a valid access token.

This boundary is particularly valuable during review because it keeps parser evidence from being promoted into an identity assertion.

Reconcile all ten expected outcomes

The recorded CPython 3.12.14 commissioning run reports that every independently authored expected list and classification matched. In the explanation below, A and B abbreviate owned-A and owned-B; the source above retains the exact strings.

The same run reports that every body sentinel remained unchanged and every parser_defects list was empty for this ten-case corpus. Those observations are useful controls for the specific bytes tested. They do not establish validity for malformed headers, obsolete folding, non-ASCII credentials, arbitrary whitespace patterns, oversized fields, or other inputs absent from the corpus.

Likewise, the observed get() behavior in H02 and H03 does not alter the expected policy. Python’s maintained documentation still states that duplicate single-value selection is undefined.

The local pass therefore means: on that runtime, for those ten authored ASCII header blocks, the parser representation and classifier matched the independently authored expectations.

Recognize an incomplete run

A useful rerun needs more than a filename called “results.”

Require, at minimum, a zero process exit status, JSON status PASS_10_CASES, all ten unique case identifiers H01 through H10, and matching expected versus observed classifications. An expected rejection such as REJECT_MULTIPLE_AUTHORIZATION is a successful policy test when it matches its authored oracle.

A raised require() exception is different. It means the laboratory itself failed before the complete report was printed.

That distinction matters with shell redirection. A command can create or truncate security_http_headers_results.json before Python fails. An empty or incomplete file is therefore not evidence that the rejection logic passed.

Preserve stderr separately. If a future interpreter reports a warning, exception, or changed behavior, record it rather than filling in missing rows from the expected table.

The source digest should also be interpreted narrowly. A changed digest means the bytes differ; it does not say whether the change is security-relevant. Conversely, the recorded digest is not a signature or proof that a production application ran this source.

Record useful decisions without copying credentials

A controlled fixture and production diagnostics have very different data-handling requirements.

The laboratory can safely print Bearer owned-A and Bearer owned-B because those strings were authored specifically for this experiment and are not genuine credentials. That does not justify logging live Authorization values in an application.

For broader context on separating useful security evidence from sensitive request data, see Refonte’s discussion of API security decision evidence.

A minimal integration record for this admission check could instead contain the adapter implementation or version, a service correlation identifier, the retained Authorization occurrence count, the admission-policy revision, and one classification such as REJECT_MISSING_AUTHORIZATION, REJECT_MULTIPLE_AUTHORIZATION, or REJECT_CREDENTIAL_SHAPE.

That is an integration design recommendation, not telemetry produced or measured by this fixture.

Those fields provide enough structure for an operator to distinguish three materially different conditions without copying credential contents. A zero count indicates that the representation presented no Authorization value. A count greater than one identifies a multiplicity rejection. A count of one paired with a shape rejection identifies a different boundary failure.

The record should still be governed by the service’s normal data-handling and retention requirements. A correlation identifier can itself have privacy or operational implications depending on the system.

Do not describe such telemetry as “raw-header evidence” unless the adapter actually captured raw lines. HTTPMessage.get_all() exposes the values retained by that object. It cannot reconstruct transport bytes, intermediary transformations, or a field that an earlier component already discarded.

That distinction avoids a common evidence inflation: logging “count=1” at a late adapter may accurately describe that adapter’s object while saying nothing about multiplicity before an upstream normalization step.

Repair the receiving adapter without inventing lost evidence

If the receiving adapter actually exposes the HTTPMessage representation tested here, the bounded repair is straightforward: call its all-values accessor for Authorization, apply the exactly-one rule, and only then inspect the surviving value’s shape.

The important part is not the three-line conditional. It is locating the check at a boundary where the required evidence still exists.

http.client.parse_headers() returns HTTPMessage, and Python’s http.server.BaseHTTPRequestHandler uses a message-class interface that defaults to http.client.HTTPMessage for headers. That makes the representation relevant to some receiving code, but this fixture does not instantiate BaseHTTPRequestHandler or qualify http.server as a deployed server path.

A framework adapter that supplies some other header abstraction needs separate review. Determine whether it preserves duplicate occurrences, combines them, rejects them, or exposes only a normalized value. Do not paste classify_shape() into an arbitrary framework and infer that the original request had the same representation as this in-memory buffer.

If only a collapsed mapping remains, information about original multiplicity may already be unavailable. At that point, the correct response is not to synthesize an imagined source representation. Move the evidence check to an earlier appropriate boundary, or hold the integration claim until the path is understood.

The same rule applies to identical duplicates. Do not deduplicate them to make the request eligible. Do not split H08-style comma text and choose a preferred fragment. Both actions replace the declared policy with unreviewed normalization.

This workflow is also different from duplicate-name handling inside JSON objects. The body decoder and its parser hooks are outside the present boundary. Here, the tested HTTPMessage still retains the repeated field values needed for the decision.

The repair objective is modest: preserve and inspect the evidence needed for this receiving-side admission policy, without pretending to recover evidence that disappeared upstream.

Define the next validation stage and integration limits

A useful design handoff can be written as a contract.

The adapter owns structural eligibility: retrieve all retained Authorization values, require exactly one, and require that one string to match the endpoint’s selected Bearer shape. The authenticator owns the real credential validation rules. Endpoint authorization and the protected business operation remain separate responsibilities.

That separation aligns with broader secure API validation foundations, but the evidence in this article remains much narrower than a general API-security architecture.

For each broader assertion, demand matching evidence.

To claim “our local parser adapter rejects duplicate Authorization fields,” test the adapter representation with a corpus such as this one and preserve the runtime and outcomes.

To claim “our HTTP server rejects them,” exercise the actual server request path.

To claim “our reverse proxy preserves the multiplicity that the adapter sees,” test that intermediary and downstream observation together.

To claim “the request was authenticated,” exercise the real authenticator with credentials and outcomes appropriate to that separate test.

To claim “the operation was authorized,” test authorization and protected behavior separately.

The body sentinel illustrates the same discipline. Python documents that parse_headers() leaves the input positioned to read the body, and the fixture confirms that owned-body-bytes\n remained unread in these buffers.

That does not qualify request framing, body-length processing, a server’s parser state, or every production body. No start-line or framing layer was involved.

Hold claims about untested intermediaries

Upstream components can present a materially different representation from the one authored in this fixture.

The experiment therefore makes no claim that a proxy, load balancer, WSGI or ASGI adapter, HTTP gateway, framework, or other intermediary will preserve, combine, reject, or discard duplicate Authorization fields. Those behaviors require evidence from the actual path.

RFC 9110 defines general semantics for field combination and explicitly conditions repeated-field generation on the field definition. That protocol context is not evidence that a particular intermediary implements one specific transformation for Authorization.

HTTP/2 paths are also untested here. So are malformed-header corpora, obsolete folding behavior, non-ASCII credentials, resource limits, unusual whitespace, and production middleware.

An adapter cannot infer multiplicity that its input representation no longer exposes. If the security requirement depends on earlier distinctions, qualify that earlier boundary before making the integration claim.

Assign ownership and a bounded release decision

A small admission check is easier to sustain when each claim has an owner and a clear release consequence.

The API owner should define the field cardinality and credential-profile contract. That includes the policy choice that one Authorization occurrence is allowed and multiple occurrences are rejected rather than normalized.

The adapter maintainer owns the interface that supplies evidence for that decision. In an HTTPMessage path, that means using get_all() rather than assuming a single-value accessor proves uniqueness. Python’s documentation is the contract to cite when reviewing that choice.

The security reviewer owns the boundary language: shape eligibility must remain distinct from authentication, and authentication must remain distinct from authorization.

QA owns the regression corpus, interpreter/runtime metadata, authored oracles, exit status, and preservation of changed observations rather than quietly rewriting expectations. Refonte’s overview of security regression testing in delivery pipelines provides broader testing context; the acceptance gate here is the much smaller ten-case contract.

Introducing a duplicate-field rejection can have compatibility impact if an existing receiver previously selected one value. That is not a reason to silently preserve ambiguous behavior. It is a reason to examine actual client behavior and the deployed service path before rollout.

The fixture performed no release, deployment, rollback, migration, or client census. A production rollout decision therefore requires evidence beyond PASS_10_CASES.

For this laboratory, acceptance is bounded and auditable:

1. All ten named cases must be present once.

2. Their independently authored expected value lists must remain unchanged unless the policy itself is deliberately revised.

3. Observed classifications must match the expected labels.

4. The body sentinel and corpus-specific defect controls must pass.

5. Process exit status must be zero and the report status must be PASS_10_CASES.

6. Runtime and source digest must be retained with the result.

7. The report must continue to state that authentication and network use are false.

8. Any source, runtime, parser, or adapter change that matters to the claim requires a new reconciled observation.

If a proposed integration cannot retain enough evidence to determine the required cardinality, hold that integration claim rather than weakening the one-field policy implicitly.

Build security review habits around explicit admission checks

The durable habit is simple: state the field-specific rule before choosing an accessor, inspect all retained occurrences relevant to that rule, and evaluate the selected credential shape only after cardinality is known.

For this HTTPMessage workflow, that means get_all("Authorization", []) answers the occurrence question that get() cannot prove on its own. Python explicitly supports duplicate fields and documents duplicate single-value selection as undefined.

Then apply the bounded whole-value Bearer rule. RFC 6750 supplies the credential grammar, and Python’s fullmatch() supplies a convenient whole-string check; neither turns owned-A or owned-B into a real credential.

The practical decision remains explicit: missing is rejected, multiple retained fields are rejected, one nonconforming value is rejected, and one structurally eligible value receives only ADMIT_TO_AUTHENTICATOR. Authentication belongs to the next validated stage.

The ten-case commissioning run supports that local conclusion for its owned ASCII buffers on CPython 3.12.14. It does not establish how an untested framework, intermediary, HTTP/2 path, malformed input, or production authentication stack behaves.

For readers building the broader review discipline behind such boundaries, Refonte Learning’s Cybersecurity & DevSecOps programme currently lists foundations including OWASP threat modeling, application-security testing, network and cloud security, and secure CI/CD practices. Those confirmed topics are relevant to learning how to define, test, and preserve security contracts without treating a local parser check as an entire authentication system.