[Webpush] Require the TTL header

Benjamin Bangert <bbangert@mozilla.com> Fri, 05 February 2016 02:12 UTC

Return-Path: <bbangert@mozilla.com>
X-Original-To: webpush@ietfa.amsl.com
Delivered-To: webpush@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F30CA1B2CCD for <webpush@ietfa.amsl.com>; Thu, 4 Feb 2016 18:12:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaT3psE6xiUZ for <webpush@ietfa.amsl.com>; Thu, 4 Feb 2016 18:12:33 -0800 (PST)
Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B1801B2CCF for <webpush@ietf.org>; Thu, 4 Feb 2016 18:12:32 -0800 (PST)
Received: by mail-yw0-x236.google.com with SMTP id h129so40346537ywb.1 for <webpush@ietf.org>; Thu, 04 Feb 2016 18:12:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=wruFaeLabbyZiXpcOYUA8gXy5tK+iYy/qH53oeQpzzE=; b=NEPuavFnZojNQ2QUBGofCGpGjHQK3dTChLS/KgT4AAGyp03ZhdyAgcwe+ASujsDeur +jHL1NHeTJX1ltydb7cz4oSzEOkbmjqTv1+TEODSvt79nHyAU6rRGBVWSEtWSv3toPBo wmuFtfM27eYE4w+M5uqhEC0qWDF9ng8HxnpImwAWZKZF5UuOFFDK7/i+xXrX+/3xvUNP Hk5M4RTIIjyPnGRQ6pucjupDuCuDmvqgD8Yyd7JoqYlXx4vCnG5blxr7HX96a6lSJm7l w5vTgMeOXcaFW9XW1J0a/Kl60djOjhEUKT788B6KTViHRhbqb3EPhx+uCbvqbpyFihMf 5YmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=wruFaeLabbyZiXpcOYUA8gXy5tK+iYy/qH53oeQpzzE=; b=aH3M8VKnUQkhPhiF1wGLGty7CeRfXAaEPuQbUh1P60wLLuw7BZL/MsiF9N8Nc88/xX e4/itygbnIpYoR4c721270FIldAfYy8DXgfkiaanLj+ILHJWZ+eF43Qj19J3ZMdBWLVS 7tLXjnm6Vl/YigCsuQVhvkoY5/AD3MGJm7zjvThr+r2yIhj0APpSZUbkn6F6nOe4RgL+ OdAG9ovZ+h4SBwI7/JnGRIdaemGrZqjRS6JP8ZiDcyCEYzEYTpPQj1ZOojMaKfYvnxZF +z6CIX13/XXFzC1p1A/oTRGsU0pL3IM1jU8ROsBdfUEn9htZGYCUZ3LtQOW5HOtdmzmz Orrw==
X-Gm-Message-State: AG10YOSqNccQGRI4u5miWnwo8WTx3HkDgMqdDP30OpSLHp1+RuWd42Gt0YEbfuidJWSA8/0i/Qpz0ZvAYvZsDHmp
MIME-Version: 1.0
X-Received: by 10.13.207.65 with SMTP id r62mr6027293ywd.27.1454638352168; Thu, 04 Feb 2016 18:12:32 -0800 (PST)
Received: by 10.37.196.68 with HTTP; Thu, 4 Feb 2016 18:12:32 -0800 (PST)
Date: Thu, 4 Feb 2016 18:12:32 -0800
Message-ID: <CABp8Eu+oBj8XKWbqd9ypT_mQWzMxXDe+cBR_vqk=rJ=6tM3tFA@mail.gmail.com>
From: Benjamin Bangert <bbangert@mozilla.com>
To: "webpush@ietf.org" <webpush@ietf.org>
Content-Type: multipart/alternative; boundary=001a114e6d7e422bb6052afc6208
Archived-At: <http://mailarchive.ietf.org/arch/msg/webpush/gGK7LWYNpo8i7678QutQfnnfUlg>
Subject: [Webpush] Require the TTL header
X-BeenThere: webpush@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of potential IETF work on a web push protocol <webpush.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/webpush>, <mailto:webpush-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/webpush/>
List-Post: <mailto:webpush@ietf.org>
List-Help: <mailto:webpush-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/webpush>, <mailto:webpush-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Feb 2016 02:12:36 -0000

Can we require a TTL value for web-push notifications?

The current behavior is not obvious to an implementer and likely to lead
them to think they've successfully sent messages when they're actually
dropped.

If you omit the TTL, then the value is assumed to be 0. This results in the
message being dropped, but the 201 status is still returned. An astute
implementer will notice in this case that no Location header is present,
since no resource was actually created.

Regarding the resource creation, the spec does not clearly state whether a
Location header should be returned for a TTL of 0 since its intended that
the message is only delivered to an online user. If so, it would be useful
to mention.

In the past 2 days, out of approximately 76k webpush notifications to our
service, 23k of them were dropped due to a missing TTL header, but a 201
status was returned.

Defaulting a missing TTL header seems ripe for implementer issues (I have a
hard time believing this many dropped notifications was intentional). If it
was a required header, we could return a 401 which would very quickly alert
developers about the problem.

Cheers,
Ben