Live data from Hacker News

HTTP/2 Protocol for iOS Push Notifications

dblog.laulkar.com

11–14 of 14 posts

Re: HTTP/2 Protocol for iOS Push Notifications

#11

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?

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...

Re: HTTP/2 Protocol for iOS Push Notifications

#12

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.

Re: HTTP/2 Protocol for iOS Push Notifications

#13
post #9

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

Re: HTTP/2 Protocol for iOS Push Notifications

#14

For 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/pushprov…

> "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 a…

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.
Post reply on HN