Here's an example client that I wrote in Go for a client that doesn't have access to an HTTP/2 library. It listens for JSON on stdin. I highlighted the guts:
https://github.com/Sidnicious/pushprovider/blob/49b1f6329522...
on line 62 you do specify HTTP/2: Transport: &http2.Transport
> "Since it uses HTTP/2, you can just use an existing HTTP library (which should handle reusing the connection for multiple notifications, too)."
I doubt many non-HTTP/2 implementations will keep connections open and continually check for more data - why wait and read for Response(s) if no Requests were sent? Let alone an HTTP version sent they do not understand.
Does anyone know why Apple uses certificates instead of API keys (a la GCM) for authorization?
Apple's model uses a public/private key pair: the private key never leaves your server and Apple doesn't know it. Apple only knows the public key, in the form of a cert. Apple actually writes about the trust model in the docs: https://developer.apple.com/library/ios/documentation/Networ....
Google's model uses a shared secret (the API key) that both the client and server know.
Having worked with both systems, I prefer the ease of the shared secret model, but each system uses a fundamentally different security model.
[1] https://developer.apple.com/library/ios/documentation/IDEs/C...
Also, having the certificate helps in signing and encrypting the notification packets triggered from the server.
