APNS HTTP API with same cert/key as the binary API. Based on #149 #173
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This requires calling /addpsp again, and providing bundleid in addition to pre-existing parameters. - It would currently be impossible to migrate old subscribers from cert/key to p8 (without further changes to the way FixedData is hashed) Store the bundleid in VolatileData, so that the computed hash of the PSP remains the same, and existing subscriptions will work. Note: I think spps might change the name of their bundle id (but keep subscribers) if they change ownership, which is why this is considered VolatileData. Not 100% sure of that. Anyway, if multiple apps ever have the same certificate data, then give them different service names or different paths (to files with identical certificate contents) - Fix test failures, still need to allow requests to specify http2 - allow specifying `uniqush.http2=1` in query params for per-request APNS override (Later, when this is well tested and performance change is known, this may be in a config or always done when bundleid is known) - allow multiple APNS HTTP2 PSPs with different certificates (With the p8 approach, that wouldn't be a problem, but with client certificates, it is) This may be refactored later to be more like the binary protocol data. - Finish getting the HTTP2 protocol to work TODO: Test this with `/shutdown`. TODO: Compare performance and network usage of http2 and binary protocol.
and add a TODO
Validate header values are the expected values. This isn't comprehensive.
I suspect that the idle timeout may be related to these errors, since pushes are infrequent on stage. HTTP2 may allow 100s of "requests" simultaneously on the same HTTP2 connection, but that depends on apple's configuration.
The initial version failed to send unsubscribe updates on resChan, which is something the binary API would do. The binary provider API sends status codes to push_service.go (From a byte of the TCP response with the associated message id) In order for uniqush to properly unsubscribe, it must send the same information over resChan, so that push_service.go can unsubscribe. Long term, the abstraction would probably be flipped (Make an HTTPClient interface out of the binary provider API) Add constant definitions for the binary API's bytes.
TysonAndre
added a commit
that referenced
this pull request
Jul 14, 2017
+ New feature: Add /previewpush endpoint to preview the payload that would be generated and sent to push services. (Issue #140) This helps with debugging. + Maintenance: Update APNS binary provider API(default) from version 1 to version 2. + Maintenance: Upgrade to redis.v5 (Issue #143) + New provider: Add FCM support. (Issue #148) The parameters that would be provided to /addpsp, /subscribe, and /push are the same as they would be for GCM. (Replace "fcm" with "gcm") + New feature: Add support APNS HTTP2 API (Issue #157, PR #173) This gives more accurate results on whether a push succeeded, and should not impact Uniqush's performance. To set this up, call /addpsp (to create a new provider or modify an existing provider) with the same params you would use to create a new APNS endpoint for binary providers (including cert and key), in addition to providing `bundleid`. Currently, to make testing easy, each call to `/push` must be provided with the query param value `uniqush.http=1`. Otherwise, uniqush continues to use the APNS binary provider API. + Maintenance: Use unescaped payloads for GCM and FCM. This allows larger payloads, avoiding escaping characters such as `<` and `>` Fixes #134 go 1.8.3+ and an up to date version of golang.org/x/net/http2 are suggested (For the APNS HTTP2 API).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This requires calling /addpsp again, and providing bundleid in addition
to pre-existing parameters.
/addpsp, all fields must be provided again.E.g. for staging/debug(sandbox) applications,
sandbox=truemust be provided yet again.It would currently be difficult (inconvenient, and possibly backwards incompatible, but not impossible)
to migrate old subscribers from cert/key to p8
p8 would be currently be treated as a completely different PSP with a different subscriber set
Store the bundleid in VolatileData, so that the computed hash of the PSP
remains the same, and existing subscriptions will work.
If multiple apps ever have the same certificate/key
data but different bundle ids, then give them different service names or different paths
(to files with identical certificate contents)
https://stackoverflow.com/questions/2575552/can-i-change-the-bundle-identifier-in-my-app-after-its-been-approved
Fix test failures, still need to allow requests to specify http2
allow specifying uniqush.http2=1 in query params for per-request APNS override
(Later, when this is well tested and performance change is known,
this may be in a config or always done when bundleid is known)
allow multiple APNS HTTP2 PSPs with different certificates
(With the p8 approach, that wouldn't be a problem, but with client
certificates, it is)
Finish getting the HTTP2 protocol to work
Disable IdleTimeout (the same as GCM). Timing out after 90 seconds would make latency unpredictable, and may cause errors when pushes are infrequent or sporadic.
Bug fixes:
int64- Some responses failed to unserialize because the timestamp couldn't be converted from a number to a string in the struct.