Re: [Webpush] Require the TTL header

This matches my understanding and seems like a reasonable plan.

If you aren't persisting anything, and you don't need a good message
identifier (because you are fully proprietary on the other side), just
crank out a random number and tack it onto a junk URL.

On 17 February 2016 at 09:44, Brian Raymor <Brian.Raymor@microsoft.com> wrote:
>
> On Sat, Feb 6, 2016 at 12:48 PM, Costin Manolache <costin@gmail.com> wrote:
>
>> I assume 202 (Accepted) would be better for TTL=0 if the service is not actually storing the message.
>
> My reading of 202 (Accepted) is that it's intended for asynchronous operations:
>
> http://tools.ietf.org/html/rfc7231#section-6.3.3
>
>    The 202 response is intentionally noncommittal.  Its purpose is to
>    allow a server to accept a request for some other process (perhaps a
>    batch-oriented process that is only run once per day) without
>    requiring that the user agent's connection to the server persist
>    until the process is completed.  The representation sent with this
>    response ought to describe the request's current status and point to
>    (or embed) a status monitor that can provide the user with an
>    estimate of when the request will be fulfilled.
>
> I suggest that we require the TTL - https://github.com/webpush-wg/webpush-protocol/issues/76 -
> but maintain the current behavior where a Location is returned even for TTL=0.   There are already
> special cases in the text for TTL=0 indicating that the resource may be deleted before the user agent can
> acknowledge a message.
>
> As I noted in my earlier response to Ben, the Location resource is also subsequently required for the
> synthesized GET:
>
> https://tools.ietf.org/html/draft-ietf-webpush-protocol-03#section-7.1
>
>    Each push message is pushed as the response to a synthesized GET
>    request sent in a PUSH_PROMISE.  This GET request is made to the push
>    message resource that was created by the push service when the
>    application server requested message delivery.
>
> ...Brian
>
> _______________________________________________
> Webpush mailing list
> Webpush@ietf.org
> https://www.ietf.org/mailman/listinfo/webpush