support Urgency

[xuwei-k]

https://tools.ietf.org/html/rfc8030#section-5.3

  5.3.  Push Message Urgency

   For a device that is battery-powered, it is often critical that it
   remains dormant for extended periods.  Radio communication in
   particular consumes significant power and limits the length of time
   that the device can operate.

   To avoid consuming resources to receive trivial messages, it is
   helpful if an application server can communicate the urgency of a
   message and if the user agent can request that the push server only
   forwards messages of a specific urgency.

   An application server MAY include an Urgency header field in its
   request for push message delivery.  This header field indicates the
   message urgency.  The push service MUST NOT forward the Urgency
   header field to the user agent.  A push message without the Urgency
   header field defaults to a value of "normal".

   A user agent MAY include the Urgency header field when monitoring for
   push messages to indicate the lowest urgency of push messages that it
   is willing to receive.  A push service MUST NOT deliver push messages
   with lower urgency than the value indicated by the user agent in its
   monitoring request.  Push messages of any urgency are delivered to a
   user agent that does not include an Urgency header field when
   monitoring for messages.

   The grammar for the Urgency header field is as follows:

   Urgency = urgency-option
   urgency-option = ("very-low" / "low" / "normal" / "high")

   In order of increasing urgency:

   +----------+-----------------------------+--------------------------+
   | Urgency  | Device State                | Example Application      |
   |          |                             | Scenario                 |
   +----------+-----------------------------+--------------------------+
   | very-low | On power and Wi-Fi          | Advertisements           |
   | low      | On either power or Wi-Fi    | Topic updates            |
   | normal   | On neither power nor Wi-Fi  | Chat or Calendar Message |
   | high     | Low battery                 | Incoming phone call or   |
   |          |                             | time-sensitive alert     |
   +----------+-----------------------------+--------------------------+

                   Table 1: Illustrative Urgency Values

   Multiple values for the Urgency header field MUST NOT be included in
   requests; otherwise, the push service MUST return a 400 (Bad Request)
   status code.

[martijndwars]

Thanks, I'll add support in the next weeks.

[tekkamanendless]

So I see that urgency was added, but no release covers this yet (as of today, v5.0.2 is the latest). Is there any chance that we could get a version bump so our applications can support this?

[martijndwars]

I will do this end of next week.

[tekkamanendless]

Need any help with this? Sorry to bug you, but I'd really like urgency support.

[martijndwars]

Just released version 5.1.0 to Maven Central 😉

[tekkamanendless]

Thank you, kind sir. I recently switched from GCM to Web Push, and some of my firefighters had noted that they were getting their notifications much slower after the update. I'm hoping that setting the urgency to "high" solves their problems 🤞