HTTP/2 Protocol for iOS Push Notifications
dblog.laulkar.comFor anyone who's not familiar with APNs, this new protocol is a huge improvement. Since it uses HTTP/2, you can just use an existing HTTP library (which should handle reusing the connection for multiple notifications, too).
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...
> "example client that I wrote in Go for a client that doesn't have access to an HTTP/2 library"
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.
That was confusing. The second “client” means “a company for whom I did programming work”. Their environment doesn’t support HTTP/2 directly, so I wrote this standalone tool. By “existing HTTP library”, I mean one which supports HTTP/2 — instead of a special-purpose library for talking to APNs over its old binary protocol.
Has anyone used this successfully yet from Python? It seems like the Hyper library should be able to talk to it, but that comes with a very strong "hyper is in a very early alpha" warning: http://hyper.readthedocs.org/en/latest/
I'm interested in contributors who would be willing to implement it in Django Push Notifications: https://github.com/jleclanche/django-push-notifications
While the old binary protocol has its deficiencies, they could have been addressed with relatively minor changes. The plus side with the old protocol is that the message format itself is very simple to generate and parse. Now I have to drag an HTTP/2 library into my notification server and deal with a much more complex protocol where the vast majority of that complexity is completely unnecessary.
This will be very helpful for enterprise environments which have an HTTP proxy for external URLs. I'm guessing this improvement wouldn't need a socks proxy since this is no longer a socket protocol?
The old APNs flow seemed overly complex, especially in comparison to GCM. This seems like a big improvement.
Does anyone know why Apple uses certificates instead of API keys (a la GCM) for authorization?
Because it's fundamentally different and more secure.
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.
Just a guess but once you've completed the TLS negotiation the APNS server doesn't need to re-authenticate for the lifetime of the socket connection whereas with API keys the key would need to be verified with each notification (because a new connection would be created)?
There must be a worthwhile reason - the added complexity of certs is non-trivial [1]. Perhaps certs are deemed less easily transferable compared to API keys (simple strings)?
[1] https://developer.apple.com/library/ios/documentation/IDEs/C...
It helps the APNS server identify the sender server better since the certificate does have more details.
Also, having the certificate helps in signing and encrypting the notification packets triggered from the server.
My guess is that they tie everything to the certificates used for signing up the App