Repository navigation
fix(swift): ask for gzip so compressed responses decode - #2025
Conversation
🔵 Tier A · Mergeable after minor fixes
The Swift and Apple SDK templates now request gzip by default when callers have not supplied an
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
Reviewed |
| if !request.headers.contains(name: "accept-encoding") { | ||
| request.headers.add(name: "accept-encoding", value: "gzip") |
There was a problem hiding this 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.
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.
0c3ea9b to
4911c2a
Compare
ba86eb1
into
feat/apple-push-edge-fixes
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
Accept-Encodingof its own, NIO'sNIOHTTPRequestDecompressorsendsAccept-Encoding: deflate, gzip.deflate, but sends a raw deflate stream (it starts95 53 …). HTTP'sdeflatemeans a zlib stream, starting78 ….deflateas zlib, so it fails with a data error (-3) on every compressed response.Fix
Accept-Encoding, the clients sendAccept-Encoding: gzip, which every server and proxy decodes the same way. NIO then keeps the header instead of adding its own.setCompression(false)still sendsidentity.The server half (answering
deflatewith 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
account.get()60 times with the generated Apple SDK on macOS:inflationError(-3);swift format lint --strictandswift buildfor the generated Swift (server) and Apple (client) SDKs.Related PRs and Issues