fishfacegit/foto-duplicate-finder
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: the video's link is its Gitea page, not the raw URL, which its own CSP blocks

Browse Source 
Checked the way a browser does it rather than the way curl does, and curl had given a false green:
Gitea sends `Content-Security-Policy: default-src 'none'; style-src 'unsafe-inline'; sandbox` with
every /raw/ response. That is deliberate - it is what makes serving raw HTML and SVG safe - but it
also blocks the media load when a browser navigates straight to a video, so the tab stays blank with
no error. The same URL plays fine as a subresource, which is exactly why the file's page in Gitea
shows a player: that page embeds <video controls src=".../raw/branch/main/...mp4">.

So the declaration's link is the /src/ page URL, and /raw/ is documented as the curl-and-download
URL instead. Everything verified about both URLs is written down in step 5 - including the two ways
to get a player with no Gitea chrome around it, if that is ever wanted: an unlisted YouTube upload,
or dropping the header for this one path on the Gitea host's Caddy proxy, which must stay scoped to
store-assets/ precisely because that header is what protects raw HTML and SVG.

The file itself was never the problem: 200, video/mp4, Content-Disposition: inline, bytes
sha256-identical to the recording, and Range: bytes=0-99 -> 206 with the matching Content-Range.
This commit is contained in:
Hadrian Burkhardt
2026-10-14 13:28:49 +02:00
parent 31a0edbe61
commit 68dcbc5db6
4 changed files with 42 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/STORE_LISTING.md
+9 -5
View File
@@ -41,15 +41,19 @@ python3 tools/make-demo-photos.py # synthetic photo li
```
Committing `store-assets/` is also what *publishes* it: Gitea serves every committed file without a
login, at
login, and pushing the commit **is** the deployment step — there is no separate upload, so a
re-shot screenshot or re-recorded video goes live the moment it is pushed. There are two URL shapes,
and which one is right depends on what does the reading:
```
https://gitea.softwareapp-hb.de/fishfacegit/foto-duplicate-finder/raw/branch/main/<path>
https://gitea.softwareapp-hb.de/fishfacegit/foto-duplicate-finder/raw/branch/main/<path> the bytes — curl, downloads
https://gitea.softwareapp-hb.de/fishfacegit/foto-duplicate-finder/src/branch/main/<path> a page — what a browser opens
```
so pushing the commit **is** the deployment step — there is no separate upload, and a re-shot
screenshot or re-recorded video goes live as soon as it is pushed. Play's foreground-service
declaration takes its video link from exactly there; the URL is written out in
For media that distinction is not cosmetic: Gitea sends `Content-Security-Policy: default-src
'none'` with `/raw/` responses, so a video opened at a raw URL shows a blank tab, while the same file
plays on its `src` page. Play's foreground-service declaration therefore takes the **page** URL as
its video link; the reasoning and what was verified about both URLs are in
[PLAY_RELEASE_CHECKLIST](PLAY_RELEASE_CHECKLIST.md) step 5.
| Asset | Play's spec | Result | Source |