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

"c^" <c@gryning.com> Thu, 19 November 2015 16:21 UTC

Return-Path: <c@gryning.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 8F1331B2C1F for <webpush@ietfa.amsl.com>; Thu, 19 Nov 2015 08:21:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSUtrRpTcYX0 for <webpush@ietfa.amsl.com>; Thu, 19 Nov 2015 08:21:44 -0800 (PST)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 1CBA11B2C56 for <webpush@ietf.org>; Thu, 19 Nov 2015 08:21:43 -0800 (PST)
Received: by wmec201 with SMTP id c201so33796049wme.0 for <webpush@ietf.org>; Thu, 19 Nov 2015 08:21:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gryning-com.20150623.gappssmtp.com; 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; d=1e100.net; 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 10.194.90.169 with SMTP id bx9mr9192099wjb.1.1447950101316; Thu, 19 Nov 2015 08:21:41 -0800 (PST)
Received: by 10.28.171.86 with HTTP; Thu, 19 Nov 2015 08:21:41 -0800 (PST)
X-Originating-IP: [132.185.153.5]
In-Reply-To: <BY2PR0301MB0647D01CC525FCE54B2BD033831B0@BY2PR0301MB0647.namprd03.prod.outlook.com>
References: <BY2PR0301MB0647D01CC525FCE54B2BD033831B0@BY2PR0301MB0647.namprd03.prod.outlook.com>
Date: Thu, 19 Nov 2015 16:21:41 +0000
Message-ID: <CAK-1ke=XbcrCxnczkarSCLbpmmQsrN3P8eNrTnLkCzOpJ-e+gQ@mail.gmail.com>
From: "c^" <c@gryning.com>
To: Brian Raymor <Brian.Raymor@microsoft.com>
Content-Type: multipart/alternative; boundary=047d7bfd0df8711c830524e727e7
Archived-At: <http://mailarchive.ietf.org/arch/msg/webpush/cyDYWVwMen0JGe_cAO5CXbEQzmY>
X-Mailman-Approved-At: Mon, 23 Nov 2015 13:13:41 -0800
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, "webpush@ietf.org" <webpush@ietf.org>
Subject: Re: [Webpush] Proposed 5xx status code for WebPush
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: 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 (
https://tools.ietf.org/html/rfc7234#section-5.5) 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.

CraigT

On 19 November 2015 at 05:19, Brian Raymor <Brian.Raymor@microsoft.com>;
wrote:

>
> In WebPush (https://datatracker.ietf.org/doc/draft-ietf-webpush-protocol/),
> 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)
>     http://www.ietf.org/mail-archive/web/webpush/current/msg00351.html
>
>     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
>     http://www.ietf.org/mail-archive/web/webpush/current/msg00352.html
>
>     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  - https://github.com/webpush-wg/webpush-protocol/issues/49
>     Pull request -  https://github.com/webpush-wg/webpush-protocol/pull/50
>
>     Mark Nottingham commented earlier:
>
>       Status codes must be potentially applicable to *all* resources, not
> use case specific (as this seems to be). See:
>
> http://httpwg.github.io/specs/rfc7231.html#considerations.for.new.status.codes
>
>      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
>
>
>
>
>