Subject: [Webpush] status code for messages dropped before TTL expiration

From: Darshak Thakore <[email-masked]>
Date: Wed, 11 Nov 2015 20:26:46 +0000

Hi all,

During the meeting (on Nov 3rd), we had an outstanding question about specifying an appropriate HTTP status code (either a 4XX or 5XX) for situations where a push server ceases to attempt delivery prior to the advertised TTL.

Here are couple of ideas to consider (and get the discussion going :)

  1.  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)
  2.  Another option is to use the “Prefer” header (where the TTL would be a preference) and then define a new 5xx "Preference Not Honored” kind of status code that can be used in a generic way. (However Martin did point out that preferences are a soft fail so having a preference not being applied may not be an appropriate reason for a server to send back an error code)
  3.  Alternately we can define a new header (and carry the TTL as one of the tokens in the header) and a corresponding status code (preferably a 5XX code) that is in the same vein as the Expect header with the 417 code.

Regards,
Darshak

---

From: Martin Thomson <[email-masked]>
Date: Wed, 11 Nov 2015 13:23:00 -0800

Generally, I think that we wanted to ask http(bis) for opinions.  But
your suggestion here prompted a thought...

On 11 November 2015 at 12:26, Darshak Thakore <[email-masked]> wrote:
> Alternately we can define a new header (and carry the TTL as one of the
> tokens in the header) and a corresponding status code (preferably a 5XX
> code) that is in the same vein as the Expect header with the 417 code.

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.

---

From: Brian Raymor <[email-masked]>
Date: Tue, 17 Nov 2015 21:37:43 +0000

On November 11 2015 at 1:23 PM, Martin Thomson <[email-masked]> wrote:

> Generally, I think that we wanted to ask http(bis) for opinions.  

Yes. I have drafted a message and will forward to httpbis today.

> message resource is Not Found/Gone.

This is a reasonable mitigation. It's a cleaner variation to the 4XX + Acknowledgement-Data header field
proposed in the IETF 94 presentation, since the TTL is more clearly related to the failure.

In addition, if we decide to adopt Acknowledgement-Data later, this ensures that:

1. The data remains opaque. There are no reserved documented values to signal failure.
2. The data remains application specific. The push service is not a source of Acknowledgement-Data - only the user agent.