Skip to content

fix(swift): ask for gzip so compressed responses decode - #2025

Merged
ArnabChatterjee20k merged 1 commit into
feat/apple-push-edge-fixesfrom
fix/swift-request-gzip
Oct 14, 2026
Merged

ArnabChatterjee20k merged 1 commit into
feat/apple-push-edge-fixesfrom
fix/swift-request-gzip

Conversation

@ArnabChatterjee20k

Copy link
Copy Markdown
Member

What does this PR do?

Fixes DecompressionError.inflationError(-3) in the Swift and Apple SDKs. It made every compressed response fail against an Appwrite server reached directly, without a proxy, and it was one of the three errors that stopped APNs registration on a device in #2000.

Root cause

  • With decompression on and no Accept-Encoding of its own, NIO's NIOHTTPRequestDecompressor sends Accept-Encoding: deflate, gzip.
  • Appwrite picks deflate, but sends a raw deflate stream (it starts 95 53 …). HTTP's deflate means a zlib stream, starting 78 ….
  • NIO inflates deflate as zlib, so it fails with a data error (-3) on every compressed response.
Accept-Encoding: gzip           → Content-Encoding: gzip     1f 8b …  (gzip)
Accept-Encoding: deflate        → Content-Encoding: deflate  95 53 …  (raw deflate, not zlib)
Accept-Encoding: deflate, gzip  → Content-Encoding: deflate  ← what NIO asked for

Fix

  • When the app hasn't set Accept-Encoding, the clients send Accept-Encoding: gzip, which every server and proxy decodes the same way. NIO then keeps the header instead of adding its own.
  • On the Apple client this applies only while compression is on; setCompression(false) still sends identity.

The server half (answering deflate with a zlib stream) is worth fixing in Appwrite too, but older servers stay in use, so the clients shouldn't depend on it.

Test Plan

  • Against a local Appwrite, account.get() 60 times with the generated Apple SDK on macOS:
    • before: 60/60 failed with inflationError(-3);
    • after: 0 failed.
  • swift format lint --strict and swift build for the generated Swift (server) and Apple (client) SDKs.
  • Generation suite and Twig lint.

Related PRs and Issues

@hansi-codes

hansi-codes Bot commented Oct 14, 2026

Copy link
Copy Markdown

🔵 Tier A · Mergeable after minor fixes

The implementation is narrow, but the gzip negotiation and compressed-response decoding behavior lacks automated regression coverage.

The Swift and Apple SDK templates now request gzip by default when callers have not supplied an Accept-Encoding header. The Apple client applies this only when response decompression is enabled, preserving its identity-encoding behavior when compression is disabled.

Verdict New comments Fixed Still open
✅ Approved 1 0 0
Finding Where
🟡 Add a regression test for gzip response decoding templates/swift/Sources/Client.swift.twig:338
Fix with agent prompt
### Issue 1
templates/swift/Sources/Client.swift.twig:338-339
**Add a regression test for gzip response decoding**

The Swift and Apple e2e suites exercise API calls, but none covers a compressed response or verifies this negotiation. Without an automated regression for the raw-deflate failure this change fixes, a later change could restore the failing behavior while the existing suites still pass.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.
📂 Walkthrough · 2
File Change
templates/apple/Sources/Client.swift.twig Adds gzip negotiation when compression is enabled and no encoding header is present.
templates/swift/Sources/Client.swift.twig Adds gzip negotiation when no encoding header is present.

Reviewed 0c3ea9b · Details · Comment @hansi-codes review to re-run, or mention @hansi-codes with a question.

@hansi-codes hansi-codes Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔵 Tier A · Looks good to merge. Summary

Comment on lines +338 to +339
if !request.headers.contains(name: "accept-encoding") {
request.headers.add(name: "accept-encoding", value: "gzip")

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add a regression test for gzip response decoding

The Swift and Apple e2e suites exercise API calls, but none covers a compressed response or verifies this negotiation. Without an automated regression for the raw-deflate failure this change fixes, a later change could restore the failing behavior while the existing suites still pass.

Prompt To Fix With AI
This is a comment left during a code review.
Path: templates/swift/Sources/Client.swift.twig
Line: 338-339

Comment:
**Add a regression test for gzip response decoding**

The Swift and Apple e2e suites exercise API calls, but none covers a compressed response or verifies this negotiation. Without an automated regression for the raw-deflate failure this change fixes, a later change could restore the failing behavior while the existing suites still pass.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

🟡 Minor · testing · Reply if this doesn't apply.

With no Accept-Encoding of its own, NIO's decompressor asks for
"deflate, gzip". Appwrite answers deflate with a raw deflate stream,
not the zlib stream HTTP's deflate names, so every compressed response
failed with DecompressionError.inflationError(-3). The Swift and Apple
clients now ask for gzip unless the app sets Accept-Encoding.
@ArnabChatterjee20k
ArnabChatterjee20k changed the base branch from main to feat/apple-push-edge-fixes October 14, 2026 08:35
@ArnabChatterjee20k
ArnabChatterjee20k merged commit ba86eb1 into feat/apple-push-edge-fixes Oct 14, 2026
61 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant