Summary
When the Sourcepoint CMP is served through Trusted Server's first-party proxy,
the privacy-manager iframe documents 404 their own assets, so the
privacy-manager UI cannot load.
Root cause
The privacy-manager iframe pages (e.g. us_pm/index.html) reference their
assets with root-absolute paths:
<script src="/PrivacyManagerUS.89867.js"></script>
<link href="/PrivacyManagerUS.b9d1f.css" rel="stylesheet">
<script src="/polyfills.01516.js"></script>
<link rel="manifest" href="/manifest.json">
On cdn.privacy-mgmt.com the iframe origin is the CDN, so these resolve
correctly. Served first-party through TS, the iframe origin is the
publisher, so /PrivacyManagerUS.89867.js resolves to the publisher root →
404. (<base href> can't help — it doesn't affect root-absolute paths.)
TS's Sourcepoint proxy already rewrites JS response bodies, but did not rewrite
the HTML iframe documents' root-absolute asset references.
Evidence
cdn.privacy-mgmt.com/PrivacyManagerUS.89867.js → 200; proxied
…/integrations/sourcepoint/cdn/PrivacyManagerUS.89867.js → 200.- In a browser through the proxy the iframe requested
/PrivacyManagerUS.89867.js
(publisher root) → 404. The request initiator was the iframe parser, not a
JS public-path — i.e. it's an HTML asset-path issue.
Fix
Rewrite root-absolute src/href in proxied Sourcepoint HTML responses to the
/integrations/sourcepoint/cdn prefix (leaving protocol-relative / absolute
URLs untouched). See the linked PR. Verified 404 → 200 in-browser.
Related / not covered here
Fixing these 404s lets the privacy-manager app render, but does not by
itself restore page scroll: the first-layer consent message iframe renders
0×0, leaving the page behind an effectively-invisible consent overlay. That
0×0 message-iframe behavior has no missing-asset cause and is a separate
first-party-proxy problem (wrapper↔message sizing/postMessage) — to be tracked
separately and likely needs an upstream Sourcepoint change.
Summary
When the Sourcepoint CMP is served through Trusted Server's first-party proxy,
the privacy-manager iframe documents 404 their own assets, so the
privacy-manager UI cannot load.
Root cause
The privacy-manager iframe pages (e.g.
us_pm/index.html) reference theirassets with root-absolute paths:
On
cdn.privacy-mgmt.comthe iframe origin is the CDN, so these resolvecorrectly. Served first-party through TS, the iframe origin is the
publisher, so
/PrivacyManagerUS.89867.jsresolves to the publisher root →404. (
<base href>can't help — it doesn't affect root-absolute paths.)TS's Sourcepoint proxy already rewrites JS response bodies, but did not rewrite
the HTML iframe documents' root-absolute asset references.
Evidence
cdn.privacy-mgmt.com/PrivacyManagerUS.89867.js→ 200; proxied…/integrations/sourcepoint/cdn/PrivacyManagerUS.89867.js→ 200./PrivacyManagerUS.89867.js(publisher root) → 404. The request initiator was the iframe parser, not a
JS public-path — i.e. it's an HTML asset-path issue.
Fix
Rewrite root-absolute
src/hrefin proxied Sourcepoint HTML responses to the/integrations/sourcepoint/cdnprefix (leaving protocol-relative / absoluteURLs untouched). See the linked PR. Verified 404 → 200 in-browser.
Related / not covered here
Fixing these 404s lets the privacy-manager app render, but does not by
itself restore page scroll: the first-layer consent message iframe renders
0×0, leaving the page behind an effectively-invisible consent overlay. That
0×0 message-iframe behavior has no missing-asset cause and is a separate
first-party-proxy problem (wrapper↔message sizing/postMessage) — to be tracked
separately and likely needs an upstream Sourcepoint change.