Domino on Linux/Unix, Troubleshooting, Best Practices, Tips and more ...

Traveler 11 HTTP/2 Push changes in detail - Review before updating

Daniel Nashed  5 February 2020 09:21:07

Detlev Pöttgen and I ran into this with the first deployments and we put together the details behind it (so you will find the same blog post on his blog and my blog).
There will be a documentation update from HCL side. Here is what we found out in detail with the feedback we got from the Traveler team.



Beginning with Traveler 11 the new push API is used -- > https://developer.apple.com/news/?id=11042019a
This is the new recommended push service from Apple which every service should use.
The older API will be available until November 2020!

There is no change needed to change to the new API and Traveler uses the new push API by default.


But your infrastructure also needs to be ready for this change!

If you have to disable the new API to go back to the "legacy API", because you can't change your infrastructure right now, there is just one notes.ini parameter that you need to set:


NTS_PUSH_APNS_HTTP2=false


But you should only use this as a very temporary solution and switch to the new push API as soon as you can!

The statement in release documentation is quite short and doesn't go into the details of what this might mean for your environment. Let me explain the changes in detail:


New Protocol HTTP/2


If you are behind a proxy, you have to check if your proxy supports the HTTP/2 protocol!  You might run into connectivity issues depending on the proxy.


Port change from 2197 to 443


The new port used is the standard HTTPS port 443 instead of  the APNS "legacy" port 2197.

You have to check your firewall if the port is open! Usually network admins are more happy with the standard port 443 but it might not be open in your environment by default!


The new HTTP/2 Push services is also available on port 2197 on the new servers to allow a more smooth migration.

There are NTS parameters you could use to change the default port 443 to the old legacy port if you really need to.


There are specific settings for each different push service and they look like this:


Example for the Verse app: NTS_PUSH_APNS_APPLE_VERSE_IBM_PRODUCTION_SERVER_PORT


If you don't set the parameter explicitly the NTS_PUSH_APNS_HTTP2 will take care of changing the port to 443 for all push Apple services.

So this is more a work-around which you should only use for example if it takes time to change your firewall.



Change from gateway.push.apple.com to api.push.apple.com


Also the target servers have changed. Before Apple used gateway.push.apple.com and switched to api.push.apple.com
Usually there isn't any change needed in your infrastructure. I checked which servers are currently behind the DNS entries and they are coming from the same netblock at Apple (see references below).



Conclusion


You really have to check your environment to see if you are prepared for new APNS HTTP/2 API.

Not having the right prerequisites isn't a reason to not update to Traveler 11. You could use the legacy API for a couple of weeks or some of the settings above might help you to get it working for your environment.

If your environment uses APNS Push, you have to migrate your environment to Traveler 11
before November 2020!


Daniel



References:



Developer Information for APNS


https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/sending_notification_requests_to_apns/

Current DNS Settings
:


gateway.push-apple.com.akadns.net

Aliases: gateway.push.apple.com

17.188.142.26
17.188.140.27
17.188.128.157
17.188.132.21
17.188.130.28
17.188.133.27
17.188.136.22
17.188.138.21


api.push-apple.com.akadns.net

Aliases: api.push.apple.com

17.188.161.182
17.188.161.11
17.188.161.203
17.188.160.13
17.188.164.15
17.188.162.16
17.188.163.207
17.188.161.13



Whois Extract for Apple Net-Block


NetRange:       17.0.0.0 - 17.255.255.255
CIDR:           17.0.0.0/8
NetName:        APPLE-WWNET
Organization:   Apple Inc. (APPLEC-1-Z)




Archives


  • [IBM Lotus Domino]
  • [Domino on Linux]
  • [Nash!Com]
  • [Daniel Nashed]