Server: Refactor Gzip exclusions to use a custom func #2457

New issue

Open

opened 2026-02-20 01:11:47 -05:00 by deekerman · 0 comments

deekerman commented

2026-02-20 01:11:47 -05:00

Owner

Originally created by @lastzero on GitHub (Dec 12, 2025).

Originally assigned to: @graciousgrey on GitHub.

As an admin, developer, and user, I want PhotoPrism to avoid gzip-compressing binary/streaming endpoints (downloads, previews, ZIP streams, health checks) so that responses remain correct for clients (including range/stream consumers) and server CPU overhead is reduced.

Binary downloads and zip streams don’t benefit from gzip and can cause correctness issues with range/stream semantics; skipping compression is both a performance and compatibility improvement.
Health endpoints are frequently polled and small; gzip adds overhead with negligible benefit.
The predicate avoids regex matching and uses fast checks (FullPath matches, prefix checks, extension map lookups)

Acceptance Criteria

Gzip compression remains enabled/disabled based on HttpCompression config option
Exclusions are preserved for:
- already-compressed/binary extensions (.jpg, .png, .mp4, .zip, etc.)
- existing excluded API path prefixes (e.g., thumbs, downloads, zip, albums, labels, videos)
Additional endpoints are excluded from gzip:
- photo original download (/api/v1/photos/:uid/dl)
- Portal theme ZIP download (/api/v1/cluster/theme)
- share preview JPEG (/s/:token/:shared/preview)
- health endpoints (/livez, /health, /healthz, /readyz)
Test coverage verifies:
- normal “text” responses are gzipped when requested
- all excluded endpoints are not gzipped even when Accept-Encoding: gzip is set
- responses without Accept-Encoding: gzip are not gzipped
- 404 responses are not gzipped

Originally created by @lastzero on GitHub (Dec 12, 2025). Originally assigned to: @graciousgrey on GitHub. **As an admin, developer, and user, I want PhotoPrism to avoid gzip-compressing binary/streaming endpoints (downloads, previews, ZIP streams, health checks) so that responses remain correct for clients (including range/stream consumers) and server CPU overhead is reduced.** - Binary downloads and zip streams don’t benefit from gzip and can cause correctness issues with range/stream semantics; skipping compression is both a performance and compatibility improvement. - Health endpoints are frequently polled and small; gzip adds overhead with negligible benefit. - The predicate avoids regex matching and uses fast checks (FullPath matches, prefix checks, extension map lookups) ### Acceptance Criteria - [x] Gzip compression remains enabled/disabled based on `HttpCompression` config option - [x] Exclusions are preserved for: - already-compressed/binary extensions (`.jpg`, `.png`, `.mp4`, `.zip`, etc.) - existing excluded API path prefixes (e.g., thumbs, downloads, zip, albums, labels, videos) - [x] Additional endpoints are excluded from gzip: - photo original download (`/api/v1/photos/:uid/dl`) - Portal theme ZIP download (`/api/v1/cluster/theme`) - share preview JPEG (`/s/:token/:shared/preview`) - health endpoints (`/livez`, `/health`, `/healthz`, `/readyz`) - [x] Test coverage verifies: - normal “text” responses are gzipped when requested - all excluded endpoints are not gzipped even when `Accept-Encoding: gzip` is set - responses without `Accept-Encoding: gzip` are not gzipped - 404 responses are not gzipped