はい、「想定しておくべき」です。
✅ 結論：
たとえリクエストヘッダーに Accept-Encoding: gzip を指定していなくても、
サーバーが Content-Encoding: gzip を付けて gzip 圧縮してくるケースはあります。
🔍 なぜそんなことが起きるのか？
1. サーバー設定が強制 gzip
- サーバーやリバースプロキシ（例：Nginx、Apache、CDN）が「常に gzip 圧縮する」設定になっていることがあります。
- クライアントの
Accept-Encodingを無視して、無条件にContent-Encoding: gzipを付けて返すケース。
2. バグ・誤設定
- 本来
Accept-Encodingを見て圧縮すべきですが、設定ミスや実装バグで無視されることがあります。
3. 中間プロキシの介入
- 中間の CDN やリバースプロキシ（Cloudflare、Akamai など）が自動的に gzip 圧縮してレスポンスを書き換えていることもあります。
🧪 実例：Java の WebClient / HttpClient などで起こりうる症状
- クライアントが
Accept-Encodingを指定していないと仮定。 - サーバーが
Content-Encoding: gzipを付けて gzip 圧縮されたボディを返す。 - クライアントがそれを 非圧縮のレスポンスと誤認 すると → ゴミデータ・文字化け・パース失敗などが起きる。
✅ どう対応すべきか？
✔ サーバー側がどう返してくるかを 常にチェック：
HTTP/1.1 200 OK
Content-Encoding: gzip
があれば、ボディは gzip 圧縮されていると判断し、クライアント側で展開する必要があります。
✔ クライアントでの安全な実装（例: Java）
WebClient（Spring）
- Spring WebClient は
Accept-Encodingを自動で送ります。 - 受信時に
Content-Encodingを見て、自動で解凍してくれます。 - ただし、手動で
Accept-Encodingを空にしても、Netty の内部実装で勝手に gzip 対応してしまうこともある。
HttpURLConnection（Java標準）
-
Accept-Encodingを送らなければ gzip 展開されません。 - でも
Content-Encoding: gzipが返ってきたら、自力で GZIPInputStream で展開する必要があります。
🎯 まとめ
| 条件 | gzip圧縮レスポンスが来る可能性 | クライアントで展開が必要か |
|---|---|---|
Accept-Encoding: gzip を送った |
高い（当然） | 自動 or 明示的に展開 |
| 送らなかった | ある（特に CDN 経由時） | 念のため展開処理を用意すべき |
✅ 推奨アプローチ
-
Content-Encodingがgzipのときは、常に gzip 解凍する処理を用意しておく。 - Java などの低レベル実装では、
Accept-Encodingの有無にかかわらず、Content-Encodingを見て判断。