# Ticket: Suppress ineffective COOP header on HTTP qualifier

Status: completed
Type: ticket
Updated: 2026-08-06
Next Action: none; retain HTTPS termination as a separate transport-security upgrade
Parent: work/wp/active/wp-build-standalone-pi-sd-qualification-operator-application.md

## Problem

The production qualifier is currently served from the non-trustworthy HTTP origin
`http://srv-rpi00.local/sd-qualifier/`, while Django emits
`Cross-Origin-Opener-Policy: same-origin`. Browsers must ignore that header on
this origin and report a console warning, making the deployed security posture
look broken even though the header has no effect over HTTP.

## Expected Behavior

HTTP deployments omit the ineffective COOP header. HTTPS deployments retain an
explicit path to enable `same-origin`. The change must be deployable to the web
service without restarting or otherwise interrupting the active Controller A
campaign services or their qualified command and notification workers.

## Acceptance Criteria

- [x] Default HTTP responses omit `Cross-Origin-Opener-Policy`.
- [x] Secure deployments can configure `Cross-Origin-Opener-Policy: same-origin`.
- [x] Automated tests cover both omitted and enabled header behavior.
- [x] Operator documentation explains that HTTPS is the transport-security
      upgrade and that the HTTP header was already ignored by browsers.
- [x] The exact source image is deployed web-only with campaign systemd services
      and worker containers continuously active.
- [x] Live response headers and a browser check confirm the warning is absent.

## Verification

Run the targeted and full Linux-container test suites, inspect production
response headers with an HTTP client, and load the deployed page in Chromium
while collecting console messages. Record service continuity and exact image
identity in a dated evidence artifact.

Completed evidence: `work/evidence/sd-qualifier-http-coop-header-20260806.md`.
