Re: [w3c/push-api] User Agents should report accepted content-encoding types. (#251)

_(Google hat)_

I support this. I'll echo Martin's comment that the data should not be associated with a `PushSubscription` instance because it applies to the user agent, as we assume that the push service will simply pass the payload through.

I'm ambivalent about whether a property to indicate whether messages without a payload—which therefore are unauthenticated— should be added. In practice all implementations support this and the specification specifically allows for this ([11.2.2.5](https://w3c.github.io/push-api/#receiving-a-push-message)), so I'm not convinced anyone would actually use it.

_(Editor hat)_

We're _very_ close to marking v1 as done, as in, this very week. I would be OK including this since it's trivial and has clear benefit, but would like to see support on this from @martinthomson and @ShijunS.

Proposal:
```webidl
partial interface PushManager {
    static readonly attribute FrozenArray<DOMString> supportedContentEncodings;
};
```

Since the `PushManager` is available in documents, as well as service, shared and dedicated workers, it's broadly usable as the following example:

```javascript
if (PushManager.supportedContentEncodings.includes('aes128gcm')) { .. }
```

If others think that adding a boolean for indicating whether empty messages are supported has sufficient value we'd add a static boolean. Admittedly it's a cheap addition, but I'm stuck in regards to what to name it. `supportsEmptyPayload` with some extra language in [11.2.2.5](https://w3c.github.io/push-api/#receiving-a-push-message)?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/push-api/issues/251#issuecomment-295924288