
HTTP/2 Protocol for iOS Push Notifications - drl42
https://dblog.laulkar.com/http2-protocol-for-apns.html
======
Sidnicious
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/pushprovider/blob/49b1f6329522...](https://github.com/Sidnicious/pushprovider/blob/49b1f63295229e620bc135e8028c3ef88ff81984/pushprovider.go#L53-L107)

~~~
jamieb007
> "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.

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

------
simonw
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/](http://hyper.readthedocs.org/en/latest/)

~~~
scrollaway
I'm interested in contributors who would be willing to implement it in Django
Push Notifications: [https://github.com/jleclanche/django-push-
notifications](https://github.com/jleclanche/django-push-notifications)

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

------
sbose78
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?

------
leesalminen
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?

~~~
simscitizen
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...](https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html#//apple_ref/doc/uid/TP40008194-CH100-SW11).

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.

