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

Mark Nottingham <mnot@mnot.net> Fri, 20 November 2015 04:58 UTC

Return-Path: <mnot@mnot.net>
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 A89E01A6F01 for <webpush@ietfa.amsl.com>; Thu, 19 Nov 2015 20:58:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 Bw50WfgHq9S9 for <webpush@ietfa.amsl.com>; Thu, 19 Nov 2015 20:58:22 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1831B1A6EE6 for <webpush@ietf.org>; Thu, 19 Nov 2015 20:58:21 -0800 (PST)
Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8174522E260; Thu, 19 Nov 2015 23:58:19 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <BY2PR0301MB0647D01CC525FCE54B2BD033831B0@BY2PR0301MB0647.namprd03.prod.outlook.com>
Date: Fri, 20 Nov 2015 15:58:16 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <0FEA24D5-A07A-465A-83CF-64B76DE5F724@mnot.net>
References: <BY2PR0301MB0647D01CC525FCE54B2BD033831B0@BY2PR0301MB0647.namprd03.prod.outlook.com>
To: Brian Raymor <Brian.Raymor@microsoft.com>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/webpush/u-nJoV6Ty2Dh9IOg3coWvs8DG4M>
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: Fri, 20 Nov 2015 04:58:24 -0000

Hey Brian,

I think the other thing that needs to be discussed here is why this needs to be a status code. 

Generally, we use a status code when we need to expose semantics to generic HTTP software -- i.e., it's not specific to the payload, resource, or type thereof. 

I know that you want to keep webpush as payload "agnostic" (to perpetuate English misuse even further), but a webpush resource *is* a specific kind of resource, so it seems to be like these semantics should be in the payload body, or failing that a HTTP header.

really-really-wanting-to-avoid-building-another-webdav-ly yours,


> On 19 Nov 2015, at 4:19 pm, 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
> 
> 
> 
> 

--
Mark Nottingham   https://www.mnot.net/