Subject: [Webpush] Expiration (was: Protocol proposal updated)

From: Martin Thomson <[email-masked]>
Date: Fri, 10 Oct 2014 14:06:35 -0700

On 10 October 2014 13:42, Costin Manolache <[email-masked]> wrote:
> I think we're in agreement - but the draft is saying a different thing ( or
> I'm reading it wrong ).

Oh no, if anything it wrong, it's the draft.  Guarantee it.

> According to draft: when the client register or creates a channel (
> independent of them listening for notifications )
> they do get a max-age and/or Expires. That means the client app or UA must
> renew before it expires.

Yes, and this is a feature I'd like to retain.  Not that the server is
required to indicate an expiration date, just that it can.

What I'm trying to do is to reuse as much of the HTTP caching
semantics for these as possible.  Thus, notification of expiration
ahead of time - or spontaneously, like you do - both rely on the same
basic mechanism.

> The issue is how can the server send to the app the message that its channel
> needs to be renewed
> during the hanging GET, with server controlling the rate and timing - i.e.
> which synthetic GET or
> other control message is sent and with which parameters.

Yeah, so the hanging GET can just return if the whole thing needs to
reboot (rare, I hope), but I realize that the push channel expiration
is going to get confused with message expiry.  Unless the server
pushes a 410 (Gone) response for the channel.  That's unambiguous.

(I'll respond to your other comments elsewhere.)

--Martin

---

From: Costin Manolache <[email-masked]>
Date: Fri, 10 Oct 2014 14:38:43 -0700

> ahead of time - or spontaneously, like you do - both rely on the same

Since it's optional, I suppose there is no harm, just keep in mind that it
may cause harm,
it's very different from users actively going to a web page and having the
content or
cookies expire.

In this case you have 1B users making periodic herd-requests to push
servers and their
own servers - just to keep listening to a relatively infrequent message
(like hurricane warning).

> (I'll respond to your other comments elsewhere.)

I think you need to go into more details about the content of the synthetic
GET -
it'll have some headers and body, you may as well define 'Content-Type:
channel-refresh'.

Costin

---

From: Costin Manolache <[email-masked]>
Date: Fri, 10 Oct 2014 22:21:05 -0700

BTW - looks like the W3C side also has "onpushregistrationlost".
IMHO a pretty bad name ( it's not really "lost" - just needs to be updated
), but allows the
server/UA to decide when to request a refresh, instead of exposing an
expiration and letting
the serviceworker do the refresh.

I suspect other special notifications from push server to app will be
needed - IMHO in both
the API and protocol this can be nicely expressed as a message with a
defined type.

I haven't seen details about the format of the message besides 'DOMString'
in the w3c side,
however in the draft you mention 'synthetic GET' - which implies a binary
payload and
headers, so pretty normal to have Content-Type. I would assume a "From"
header will
also be present, indicating the authenticated sender - and this can also be
used to
clearly indicate messages from the push server itself.

Costin

On Fri, Oct 10, 2014 at 2:38 PM, Costin Manolache <[email-masked]> wrote:

> I think you need to go into more details about the content of the
> synthetic GET -
> _______________________________________________
> Webpush mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webpush
>
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 13 Oct 2014 10:25:09 -0700

> the serviceworker do the refresh.

Yes, that was always the intent.  The serviceworker shouldn't have to
do anything other than react to a) reported outages, and b) new or
changed endpoints (or registration identifiers).

> I suspect other special notifications from push server to app will be needed
> - IMHO in both

Why do you think that?  If the existing protocol mechanisms convey
sufficient information, there shouldn't be any need to add more
mechanisms.

> clearly indicate messages from the push server itself.

The synthesized GET is an artifact of how HTTP/2 push works.  The
response to that includes the push message.  In the current view, this
would be some sort of encrypted blob.

Why do you think we would have a From header field?  That's basically
never used in HTTP, and that implies something about authentication
that I don't think is uniformly possible.  (Yes, I still owe you a
write-up on the authentication piece.)

---

From: Costin Manolache <[email-masked]>
Date: Mon, 13 Oct 2014 11:03:36 -0700

On Mon, Oct 13, 2014 at 10:25 AM, Martin Thomson <[email-masked]>
wrote:

> needed

The protocol as specified - with synthetized GET - would convey sufficient
information
if the HTTP headers are exposed to the client API. So if the HTTP transport
remain -
I don't think we need additional notifications, not even for 'expiry',
since this
can be expressed as a message with "Content-Type:refresh" ( or similar name
).

> write-up on the authentication piece.)

My primary concern is making sure that "Content-Type" is there and used.

As any HTTP request, it would be possible to add X- headers, or to
evolve the protocol by defining specific content-types and headers instead
of requiring changes to the transport.

While the actual payload will be encrypted and not visible to the push
server-  some
of the headers in the HTTP message will be originated from the push server.
I don't know if this spec should include a list of common headers that are
specific
to push, or a subset of the HTTP headers that are likely to be present in
push.
But IMHO Content-Type should be required, and other should be mentioned -
Date ( defined as the time when the message was sent ?), Content-Encoding,
Via.

Re. From: what is the plan for the URL of the synthetized GET ? It could be
a URL that identifies the sender of the push, in the case of multiple
senders.
Otherwise - some way to indicate who sent the push will be needed, From
is normally used for this.

Costin

---

From: Martin Thomson <[email-masked]>
Date: Mon, 13 Oct 2014 14:35:22 -0700

Regarding expiration, this is something that I would expect the
browser to consume.  The application running in the browser would not
need to concern itself with refresh.  The application would only have
to react to outages (optionally), or any changes in the endpoint or
registration id (if that's possible; some systems will do that
occasionally, others are completely stable in that regard).

> Date ( defined as the time when the message was sent ?), Content-Encoding,

The current API doesn't expose this meta information.  I would like
for that to be possible.

However, I don't think that Content-Encoding is something that the
application needs to worry about, and I can't think of a use case for
Via.  The Date header is definitely useful though, since this allows
the push server to communicate the age of a message.  And I'm sure
that there are other header fields that have genuine use cases.

> is normally used for this.

The draft currently uses the channel URI - the same string that the
application needs.  The idea was that if you want to use this to
identify where it came from, you would create one for each application
server.

---

From: Costin Manolache <[email-masked]>
Date: Mon, 13 Oct 2014 15:06:03 -0700

> occasionally, others are completely stable in that regard).

The browser needs to consume it in most cases - it'll need to call
register() again, get
a brand new ID and send it to the sender app. Otherwise the sending server
would
have the expired registration.

There are 3 separate communications:
1. device to push server, where 'expiration' events happen.
2. Push server to the sending app - the sender needs a valid, unexpired
channel Id.
3. device to the sending app - that's how the sending app gets the channel
ID from device,
and will need to be able to get refreshed IDs.

We tried to update the sending server - but it doesn't work well, the send
may be very infrequent,
and in some cases the device data may become invalid/corrupted - and there
is nothing to do
to recover it except doing a brand new registration.

> that there are other header fields that have genuine use cases.

I agree - some of the headers are only relevant to the UA, while some may
or may
not be relevant to the application. For example "Via" (or similar) would
indicate
which push server was used. But I agree, the spec should only include
the headers that have clear use cases - Content-Type is one needed both
by UA and application, Content-Encoding probably only by UA..

> identify where it came from, you would create one for each application

Sounds good, than there is no need for a From header in transport, :url is
good.

But I think the app will need access to this data - it's quite important to
know which
channel (sender) originated the message - but that's on the API side, easy
to extract from url.

Costin

---

From: Martin Thomson <[email-masked]>
Date: Mon, 13 Oct 2014 15:54:36 -0700

> channel (sender) originated the message - but that's on the API side, easy

Definitely.

Currently there is a one-to-one mapping between channel
("registration" in the API, we still need to normalize terminology)
and a service worker, so there is little risk of confusion.  I've
proposed that applications be permitted to create any number of
channels though.