Re: [Webpush] Proposed 5xx status code for WebPush

"c^" <> Thu, 19 November 2015 16:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8F1331B2C1F for <>; Thu, 19 Nov 2015 08:21:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Status: No, score=-1.277 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] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mSUtrRpTcYX0 for <>; Thu, 19 Nov 2015 08:21:44 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1CBA11B2C56 for <>; Thu, 19 Nov 2015 08:21:43 -0800 (PST)
Received: by wmec201 with SMTP id c201so33796049wme.0 for <>; Thu, 19 Nov 2015 08:21:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bsfBbPiWhUZLWlVrbicjRaAdczTo4y1mH196iNg+RVc=; b=kptqN5/gmvR5KP7mHug1XoAmixzFlVKFGbz88YIoqlRifa66WdOd+C/f1kaVENjBB0 sdArqXNXmCn+BBPa0pS8LZG5sGf3zaZXEP7ZzAnSgE8zyxS2RfcEiCHt9mAlgyjSoatW rf56Mv23I6RDjlatojGvpoIMF7+W3Irer302HTlF3qEIaIkRocGw9ry9mXUG2YrCIX+n OVGZGIt9lYGm2bmtoTE/mHAixMXXlAhMYXgRE34hgJoHfcT4+thNoKRGDJdp7Do3+VK1 vMTleKPJ20BL391DOiiuQ5mEi70Fz4eDHJpIgiM3nZ0QIqGDJBEtL53d61SlRQ1vovLf Zg6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bsfBbPiWhUZLWlVrbicjRaAdczTo4y1mH196iNg+RVc=; b=aPqtw87YYtme9t+QDhGwidGta7Wj9SN8nTswiksqZj868E8yHJPGJE8FLC7oEkWrmd zNNE9BN94hz8PabnUGzV6F04oggsmZYIxzeK+CeByFj/l9tftX5LoTpvYRptQ7o0Fa6X YnAm+Oti0CW2S8nG84q2pkIRVN8kOfQEvNUelJFbYj3YP+ot/cgy4f0vpjQTszQj4G5m ShZ9iZaEkU1x2EWxaGYfqdH78zK629rdUxRoMWUL0kA+j3D5QYUkgcQOdGLts+R+Icb1 KC9wwGLnFv9TtU8kK9iyXE68ySQjygolZKF5tlFGpni+a+72LU8F5uJRiakUexMy4ux6 zeYA==
X-Gm-Message-State: ALoCoQnWBb8YVm58NnNmTgXpNWYaM6JqTwKi7lqsV/qIBxuYNEagpiCxdfWFFqhN91DzwITyMS/p
MIME-Version: 1.0
X-Received: by with SMTP id bx9mr9192099wjb.1.1447950101316; Thu, 19 Nov 2015 08:21:41 -0800 (PST)
Received: by with HTTP; Thu, 19 Nov 2015 08:21:41 -0800 (PST)
X-Originating-IP: []
In-Reply-To: <>
References: <>
Date: Thu, 19 Nov 2015 16:21:41 +0000
Message-ID: <>
From: "c^" <>
To: Brian Raymor <>
Content-Type: multipart/alternative; boundary=047d7bfd0df8711c830524e727e7
Archived-At: <>
X-Mailman-Approved-At: Mon, 23 Nov 2015 13:13:41 -0800
Cc: "" <>, "" <>
Subject: Re: [Webpush] Proposed 5xx status code for WebPush
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of potential IETF work on a web push protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Nov 2015 16:21:49 -0000

A few thoughts I shared privately with Martin in Yokohama:

My starting assumption is that the resource is created on the push service,
and the push service is authoritative as to it's status.


410: Makes sense as in the draft to provide a normalised response; 1
response for absolute completion, I have administratively removed this
resource and I do not intend to return it.

5xx: Indicating a failed DELETE to remove the relationship of subscriber
/d/bbb resource isn't what I'd expect. Given we are simulating a GET from
the application to assert the status of a resource, where the stated use of
'gone' is used to indicate having administratively/intentionally removed
this resource. To then return a 5xx in the contrary case, indicating that
there is a server issue in asserting a response to something it should be
answering authoritatively for doesn't seem correct. I would argue that a
200/202 would be more appropriate as the push service was unable to remove
all references to the resource described as the DELETE failed; and the
negative of having something removed would be a successful response. This
could be extended to be more specific using a warning ( body or header.

New 4xx:
Finally, an alternative 4xx such as 404/409 might be applicable as a
contrary to the the 410. A new 4xx that indicates I had a representation;
but it is now expired and I can't reconcile this. This said 404 still makes
logical sense when considered as the response to a simulated get. e.g. push
service has now removed this asset, but not deliberately/administratively.
Expiration could be indicated as part of the body or header or as a warning.


Hope this helps and doesn't re-open old threads.


On 19 November 2015 at 05:19, Brian Raymor <>;

> In WebPush (,
> an application server can
> request that the push service acknowledge that it has delivered a message
> to a user agent. The push service
> indicates success (positive acknowledgement) by returning a 410 (Gone) to
> the application server.
> The push service also needs to indicate failure (negative acknowledgement)
> due to the following cases:
> 1. The user agent failed to acknowledge receipt of the message and the
> push service has ceased to attempt re-delivery of
>      the message  prior to its advertised expiration (TTL header field).
> 2. The push service expired the message prior to its advertised expiration
> due to operational constraints.
> The following approaches have been explored:
> 1. Reusing 404 (for positive acknowledgement) and 410 (for negative
> acknowledgement).
> 2. Use 417 (Expectation Failed)
>     Currently there is a 417 Expectation Failed status code already
> defined that works in conjunction with the "Expect" header.
>     Maybe we can define an "expectation" for the TTL and send it in the
> Expect header. Then if the push server drops the message
>     prematurely, it can send back a 417. (However there seems to be some
> history behind the Expect header which may be an issue)
> 3. Combine 410 (Gone) with a non-zero TTL header field to indicate failure
>     Maybe we can just use TTL.  If it is present (and therefore non-zero)
> then it's an indication that the TTL hasn't run out, even though the
>     message resource is Not Found/Gone.
> 4. Define a new 512 (Expired Resource) status code
>     Issue  -
>     Pull request -
>     Mark Nottingham commented earlier:
>       Status codes must be potentially applicable to *all* resources, not
> use case specific (as this seems to be). See:
>      When it is necessary to express semantics for a response that are not
>      defined by current status codes, a new status code can be registered.
>      Status codes are generic; they are potentially applicable to any
>      resource, not just one particular media type, kind of resource, or
>      application of HTTP.  As such, it is preferred that new status codes
>      be registered in a document that isn't specific to a single
>      application.
>   While we completely agree with Mark's assessment that this use case is
> specific to WebPush at this time,
>   the sense was that this should be in the class of 5xx Server Error
> codes. Unfortunately, after review there
>   were no existing codes related to this use case. We discussed the
> proposed status code and potential
>   mitigations at IETF 94 and agreed to broaden the discussion to the
> HTTPbis mailing list.
> Thoughts? Does anyone else have a similar use case?
> ...Brian