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

Mark Nottingham <> Fri, 20 November 2015 04:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A89E01A6F01 for <>; Thu, 19 Nov 2015 20:58:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.602
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Bw50WfgHq9S9 for <>; Thu, 19 Nov 2015 20:58:22 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1831B1A6EE6 for <>; Thu, 19 Nov 2015 20:58:21 -0800 (PST)
Received: from [] (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (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 <>
In-Reply-To: <>
Date: Fri, 20 Nov 2015 15:58:16 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Brian Raymor <>
X-Mailer: Apple Mail (2.2104)
Archived-At: <>
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: 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 <> wrote:
> 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

Mark Nottingham