···200200}
201201```
202202203203-`com.atproto.sync.getBlob` responses should stay uncompressed end-to-end. `perlsky` now bypasses Mojolicious dynamic gzip for blob bytes because some downstream image proxy routes will auto-decompress the body and accidentally forward a stale `Content-Encoding` header, which shows up in clients as broken image loads (`ERR_CONTENT_DECODING_FAILED`).
203203+`com.atproto.sync.getBlob` responses should stay uncompressed end-to-end. `perlsky` now bypasses Mojolicious dynamic gzip for blob bytes because some downstream image proxy routes will auto-decompress the body and accidentally forward a stale `Content-Encoding` header, which shows up in clients as broken image loads (`ERR_CONTENT_DECODING_FAILED`). If your reverse proxy also does response compression, exempt `/xrpc/com.atproto.sync.getBlob` from it as well.
204204+205205+For Caddy that means putting the blob path on a plain proxy path before any `encode` handler, for example:
206206+207207+```caddy
208208+@blob_download path /xrpc/com.atproto.sync.getBlob
209209+handle @blob_download {
210210+ reverse_proxy 127.0.0.1:7755
211211+}
212212+213213+handle {
214214+ encode gzip
215215+ reverse_proxy 127.0.0.1:7755
216216+}
217217+```
204218205219This still requires wildcard DNS or per-handle DNS records so public ACME validation can reach the server.
206220