APNs push notification unexpectedly succeeds over HTTP2 even if it ONLY contains content-available: 1 with apns-priority: 10

Hi,


We are developing our push notification system using APNs over HTTP2. As described in APNs documentation, it is not a valid request if we send a push notification that only contains a content available key, say with the value of 1, and setting a apns priority header field with the value of 10. Though the documentation clearly says this request is an error, which indicates a request should fail with some error response, the request actually succeeded. So we are confused with the documentation and actual API behavior we observed.


Our questions are;

1 Is the documentation correct over HTTP2.0 protocol?

2 Do we misunderstand the documentation?

> this request is an error, which indicates a request should fail with some error response


I think the first part is true, but the second part doesn't necessarily follow. It may be that the APNs server doesn't really look at payload content (beyond making sure it's not too long). The notification itself is still deliverable by the gateway, but the receiving device itself might discard the notification; it might also be that it's an error (in the sense that it's a mistake on the sender's part), but the server will still do its best to deliver the notification to the end device.

Thanks for your quick response!


All right, so it should be a bad request? (That's what I wanted to know 🙂)

Maybe we shouldn't rely on the APNs server-side validation but should make sure that a request doesn't only contain content-available and apns-priority with the valule of 10. This is a practical workaround here?

> so it should be a bad request?


I'd argue that it's legit at the protocol level, and so it shouldn't be immediately rejected by the server. I'd say it's on par with other typos in your notification payload; the APNs servers can accept the notification, but the receiving device may not know what to do with it.


> we shouldn't rely on the APNs server-side validation but should make sure that a request doesn't only contain content-available and apns-priority with the valule of 10.


I think that's the best bet, yes.

> the APNs servers can accept the notification, but the receiving device may not know what to do with it.

> I think that's the best bet, yes.


All right, thanks again! 🙂 (and thanks alot for your great work of relayrides/pushy!)

APNs push notification unexpectedly succeeds over HTTP2 even if it ONLY contains content-available: 1 with apns-priority: 10
 
 
Q