Retrieve APNS status code?

[Nate Leon]

When I use Pushy to send a notification to APNs, is it possible to retrieve the status code returned by APNS to Pushy?
i.e. this list:

0   - No errors encountered
1   - Processing error
2   - Missing device token
3   - Missing topic
4   - Missing payload
5   - Invalid token size
6   - Invalid topic size
7   - Invalid payload size
8   - Invalid token
255 - None (unknown)

I see the SimplePushNotificationResponse :: getRejectionReason() but of course, that just returns a String,
and I'm not sure what is the list of possibilities there.

If I send a bogus token, I get back rejectionReason=BadDeviceToken in the SimplePushNotificationResponse,
so I could probably guess / fish out other strings,
but just wondering if I am missing anything easier / obvious first.
I suspect this wheel has already been invented. :-)

TIA,
n8

[Nate Leon]

I guess I found the answer to the possible list of values is in Table 8-6 here:
https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/CommunicatingwithAPNs.html

but my original question about retrieving the actual APNS status code from Pushy still stands. :)

Thanks,
n8

[Jon Chambers]

Nate,

We've generally been hesitant to provide a more precise enumeration of status codes because they might change upstream. When you say you're looking for the "actual APNs status code," could you be more specific about what you mean? `getRejectionReason` returns exactly what we get from the server; are you asking for the HTTP status code? If so, could you elaborate on the use case?

Thanks!

-Jon

--
Pushy is an open-source Java library for sending APNs (iOS and OS X) push notifications. Pushy is brought to you by the engineers at RelayRides.
---
You received this message because you are subscribed to the Google Groups "pushy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pushy-apns+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nate Leon]

Welcome back - hope you had a relaxing vacation!

Yes, I am referring to the HTTP status code, e.g.    413   PayloadTooLarge

Since we are currently using the notnoop lib, we have:
https://github.com/notnoop/java-apns/blob/master/src/main/java/com/notnoop/apns/DeliveryError.java

which maps the APNS return code from Table 8-6 here:
https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/CommunicatingwithAPNs.html

Our use-case is that we are writing a RESTful service to handle the sending of the Push notifications (gratefully using your Pushy lib :) for various clients here.
Moreover, we  have a contract with those clients that we will only return a certain set of responses. (generalized across WNS, APNS, and GCM)
So our proxy maps the APNS return code to a smaller subset of client responses. (e.g. 400, 413, 500, 503)
Either way, our proxy needs to return some status code back to our HTTP clients.
It is easy enough for us to map the rejectReason string back to a numeric status code, so this is not a show-stopper by any means.
Just wanted to bounce it off the team here, since it seems unnecessarily inefficient.

Thanks!
n8

To unsubscribe from this group and stop receiving emails from it, send an email to pushy-apns+...@googlegroups.com.

[Jon Chambers]

Understood; we've generally been "hiding" HTTP/2 status codes for a few reasons:

1. They feel like a protocol-level implementation detail. In the current world view, if we're doing our job right, callers should ideally not even be aware that we're using HTTP/2 at all (because we've taken care of all of the complexity for them).

2. They don't reeeeeeeally give us any new actionable information beyond the error message. With VERY limited exception (things like "auth token has expired and needs to be renewed," which we handle internally), they all basically boil down to "no."

3. Even though it's not much, it does add a little surface area and complexity to the public API.

I can certainly understand why the status code would be helpful (though not quite necessary) in your specific use case, but I'm not sure if the benefits would outweigh the costs in the general case. Especially if you're already trying to normalize responses for your end users, I think the best bet for now is to keep doing exactly what you're doing.

Seem legit?

-Jon

To unsubscribe from this group and stop receiving emails from it, send an email to pushy-apns+unsubscribe@googlegroups.com.

[Nate Leon]

Sure, and the amount of complexity that Pushy has encapsulated for us is much appreciated. :-)
I'll go forward with switch(rejectReason) -> status code

Thanks!
n8