Proposed 5xx status code for WebPush

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

Received on Thursday, 19 November 2015 05:19:48 UTC