HTTP/2 Protocol for iOS Push Notifications
dblog.laulkar.com
HTTP/2 Protocol for iOS Push Notifications
1–10 of 14 posts
Re: HTTP/2 Protocol for iOS Push Notifications
#2For 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...
Re: HTTP/2 Protocol for iOS Push Notifications
#3The 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?
Re: HTTP/2 Protocol for iOS Push Notifications
#4The 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?
My guess is that they tie everything to the certificates used for signing up the App
Re: HTTP/2 Protocol for iOS Push Notifications
#5The 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?
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.
Re: HTTP/2 Protocol for iOS Push Notifications
#6This 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?
Re: HTTP/2 Protocol for iOS Push Notifications
#7The 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?
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)?
Re: HTTP/2 Protocol for iOS Push Notifications
#8While 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.
Re: HTTP/2 Protocol for iOS Push Notifications
#9Has 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/
Re: HTTP/2 Protocol for iOS Push Notifications
#10For 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 and read for Response(s) if no Requests were sent? Let alone an HTTP version sent they do not understand.