Subject: Proposed 5xx status code for WebPush

From: Brian Raymor <[email-masked]>
Date: Thu, 19 Nov 2015 05:19:15 +0000

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

---

From: "c^" <[email-masked]>
Date: Thu, 19 Nov 2015 16:21:41 +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 <[email-masked]>
wrote:

> 1. The user agent failed to acknowledge receipt of the message and the
> push service has ceased to attempt re-delivery of
>     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)
>
>     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
>       Status codes must be potentially applicable to *all* resources, not
> use case specific (as this seems to be). See:
>

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 19 Nov 2015 12:00:12 -0500

Hi Brian,

--On November 19, 2015 at 5:19:15 AM +0000 Brian Raymor 
<[email-masked]> 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.

It seems a little odd for "success" to be indicated by a 4xx code. Why not 
just return a 204 (No Content) for that case?

If you do that, then you can use 410 for the case where the server has 
stopped processing the push, and 503 for the "operation" failure.

If you need more fine-grained error reporting, then consider using 
<https://tools.ietf.org/html/draft-ietf-appsawg-http-problem-01> as the way 
to do that rather than inventing lots of new status codes.

-- 
Cyrus Daboo

---

From: Martin Thomson <[email-masked]>
Date: Thu, 19 Nov 2015 10:02:48 -0800

> just return a 204 (No Content) for that case?

I like this.  204 indicates that the content was removed
(successfully).  A 404/410 indicates that the resource was discarded.

Obviously, the 204 state might be immediately followed by the removal
of the resource, but we don't need to separately report that.

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 20 Nov 2015 17:34:52 +1300

On 20/11/2015 7:02 a.m., Martin Thomson wrote:
> On 19 November 2015 at 09:00, Cyrus Daboo wrote:

I agree. In a system where the resource is _moved_ from the delivery URL
to elsewhere 204 makes a lot of sense.

It is also critical that the system tracks what it has previously
processed in order to send that 204 instead of a 404 long after the
object has been moved away.

Amos

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 20 Nov 2015 15:58:16 +1100

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 <[email-masked]> wrote:
> 
> 

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