Re: Proposed 5xx status code for WebPush

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/

Received on Friday, 20 November 2015 04:58:51 UTC