{"id":616,"date":"2016-02-20T00:33:53","date_gmt":"2016-02-20T00:33:53","guid":{"rendered":"http:\/\/blog.mozilla.org\/services\/?p=616"},"modified":"2016-02-20T00:42:07","modified_gmt":"2016-02-20T00:42:07","slug":"webpushs-new-requirement-ttl-header","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/services\/2016\/02\/20\/webpushs-new-requirement-ttl-header\/","title":{"rendered":"WebPush\u2019s New Requirement: TTL Header"},"content":{"rendered":"<blockquote><p><a href=\"https:\/\/developer.mozilla.org\/en-US\/docs\/Web\/API\/Push_API\">WebPush<\/a> is a new service where web applications can receive notification messages from servers. WebPush is available in Firefox 45 and later and will be available in Firefox for Android soon. Since it\u2019s a new technology, the <a href=\"https:\/\/tools.ietf.org\/html\/draft-ietf-webpush-protocol-03\" target=\"_blank\">WebPush specification<\/a> continues to evolve. We\u2019ve been rolling out the new service and we saw that many updates were not reaching their intended audience.<\/p><\/blockquote>\n<p>Each WebPush message has a TTL (Time To Live), which is the number of seconds that a message may be stored if the user is not immediately available. This value is specified as a <code>TTL:<\/code> header provided as part of <a href=\"http:\/\/autopush.readthedocs.org\/en\/latest\/http.html#send-notification\" target=\"_blank\">the WebPush message<\/a> sent to the push server. The original draft of specification stated that if the header is missing, the default TTL is zero (0) seconds. This means if the TTL header was omitted, and the corresponding recipient was not actively connected, the message was immediately discarded. This was probably not obvious to senders since the push server would return a <code>201 Success<\/code> status code.<\/p>\n<p>Immediately discarding the message if the user is offline is probably not what many developers expect to happen. The <a href=\"https:\/\/mailarchive.ietf.org\/arch\/search\/?email_list=webpush&amp;gbt=1&amp;index=3xwqCK1mElrjyYzvNI1lJtGa8ek\" target=\"_blank\">working group decided<\/a> that it was better for the sender to explicitly state the length of time that the message should live. The Push Service may still limit this TTL to it\u2019s own maximum. In any case, the Push Service server would return the actual TTL in the POST response.<\/p>\n<p>You can still specify a TTL of zero, but it will be you setting it explicitly, rather than the server setting it implicitly. Likewise if you were to specify <code>TTL: 10000000<\/code>, and the Push Service only supports a maximum TTL of 5,184,000 seconds (about one month), then the Push Service would respond with a <code>TTL:5184000<\/code><\/p>\n<p>As an example,<\/p>\n<pre><code>\r\ncurl -v -X POST https:\/\/updates.push.services.mozilla.com\/push\/<i>LongStringOfStuff<\/i> \\\r\n-H \"encryption-key: keyid=p256dh;dh=<i>...<\/i>\" \\\r\n-H \"encryption: keyid=p256dh;salt=<i>...<\/i>\" \\\r\n-H \"content-encoding: aesgcm128\" \\\r\n<b>-H \"TTL: 60\"<\/b> \\\r\n--data-binary @encrypted.data\r\n\r\n&gt; POST \/push\/<i>LongStringOfStuff<\/i> HTTP\/1.1\r\n&gt; User-Agent: curl\/7.35.0\r\n&gt; Host: updates.push.services.mozilla.com\r\n&gt; Accept: *\/*\r\n&gt; encryption-key: ...\r\n&gt; encryption: ...\r\n&gt; content-encoding: aesgcm128\r\n&gt; <b>TTL: 60<\/b>    \r\n&gt; Content-Length: 36\r\n&gt; Content-Type: application\/x-www-form-urlencoded\r\n&gt;\r\n* upload completely sent off: 36 out of 36 bytes\r\n&lt; HTTP\/1.1 201 Created\r\n&lt; Access-Control-Allow-Headers: content-encoding,encryption,...\r\n&lt; Access-Control-Allow-Methods: POST,PUT\r\n&lt; Access-Control-Allow-Origin: *\r\n&lt; Access-Control-Expose-Headers: location,www-authenticate\r\n&lt; Content-Type: text\/html; charset=UTF-8\r\n&lt; Date: Thu, 18 Feb 2016 20:33:55 GMT\r\n&lt; Location: https:\/\/updates.push.services.mozilla.com...\r\n&lt; <b>TTL: 60<\/b>\r\n&lt; Content-Length: 0\r\n&lt; Connection: keep-alive\r\n\r\n<\/code><\/pre>\n<p>In this example, the message would be held for up to 60 seconds before either the recipient reconnected, or the message was discarded.<\/p>\n<p>If you fail to include a <code>TTL<\/code> header, the server will respond with an HTTP status code of 400. The result will be similar to:<\/p>\n<pre><code>\r\n&lt; <b>HTTP\/1.1 400 Bad Request<\/b>\r\n&lt; Access-Control-Allow-Headers: content-encoding,encryption,...\r\n&lt; Access-Control-Allow-Methods: POST,PUT\r\n&lt; Access-Control-Allow-Origin: *\r\n&lt; Access-Control-Expose-Headers: location,www-authenticate\r\n&lt; Content-Type: application\/json\r\n&lt; Date: Fri, 19 Feb 2016 00:46:43 GMT\r\n&lt; Content-Length: 84\r\n&lt; Connection: keep-alive\r\n&lt;\r\n<b>{\"errno\": 111, \"message\": \"Missing TTL header\", \"code\": 400, \"error\": \"Bad Request\"}<\/b>\r\n<\/code><\/pre>\n<p>The returned error will contain a JSON block that describes what went wrong. Refer to our <a href=\"http:\/\/autopush.readthedocs.org\/en\/latest\/http.html#error-codes\" target=\"_blank\">list of error codes<\/a> for more detail.<\/p>\n<p>We understand that the change to require the TTL header may have not reached everyone, and we apologize about that. We\u2019re going to be \u201csoftening\u201d the requirement soon. The server will return a <code>400<\/code> only if the remote client is not immediately connected, otherwise we will accept the WebPush with the usual <code>201<\/code>. Please understand that this relaxation of the spec is temporary and we will return to full specification compliance in the near future.<\/p>\n<p>We\u2019re starting up a Twitter account, <a href=\"https:\/\/twitter.com\/MozillaWebPush\" target=\"_blank\">@MozillaWebPush<\/a>, where we\u2019ll post announcements, status, and other important information related to our implementation of WebPush. We encourage you to follow that account.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>WebPush is a new service where web applications can receive notification messages from servers. WebPush is available in Firefox 45 and later and will be available in Firefox for Android soon. Since it\u2019s a new technology, the WebPush specification continues &hellip; <a class=\"go\" href=\"https:\/\/blog.mozilla.org\/services\/2016\/02\/20\/webpushs-new-requirement-ttl-header\/\">Continue reading<\/a><\/p>\n","protected":false},"author":1252,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[282887],"tags":[],"_links":{"self":[{"href":"https:\/\/blog.mozilla.org\/services\/wp-json\/wp\/v2\/posts\/616"}],"collection":[{"href":"https:\/\/blog.mozilla.org\/services\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.mozilla.org\/services\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/services\/wp-json\/wp\/v2\/users\/1252"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/services\/wp-json\/wp\/v2\/comments?post=616"}],"version-history":[{"count":0,"href":"https:\/\/blog.mozilla.org\/services\/wp-json\/wp\/v2\/posts\/616\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.mozilla.org\/services\/wp-json\/wp\/v2\/media?parent=616"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mozilla.org\/services\/wp-json\/wp\/v2\/categories?post=616"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mozilla.org\/services\/wp-json\/wp\/v2\/tags?post=616"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}