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

["c^" <[e-mail]>]

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 <[e-mail]>
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
>
>
>
>
>