web-push
web-push copied to clipboard
web-push-libs
TTL doesn't seem to be honored
Setup
Operating System: Linux Node Version: v6.2.2 web-push Version: ^3.2.2
Browser
- [x] Chrome
Problem
TTL is not honored, if I set 7200 seconds it is still shown the next morning when I fire up the browser
Expected
Notifications should expire after TTL seconds
Features Used
- [x] VAPID Support
- [x] GCM API Key
- [x] Sending with Payload
Example / Reproduce Case
const payload = new Buffer('{"title": "'+urldecode(title)+'", "body": "'+urldecode(body)+'", "icon": "'+icon+'", "href": "'+href+'", "tag": "'+tag+'"}', 'utf8');
const options = { TTL: 7200 }
webpush.sendNotification(subscription, payload, options).then(function(response) {
console.log(JSON.stringify(response));
});
Hi, I will file an issue today, but I'm not yet convinced this is on chrome/chromium side. Isn't there a way to understand what headers are sent exactly to the FCM server?
Isn't there a way to understand what headers are sent exactly to the FCM server?
You can add some logging here if you want: https://github.com/web-push-libs/web-push/blob/master/src/web-push-lib.js#L265. We have tests that check the TTL header is present though, so it shouldn't be a bug on our side.
Here's a detailed response, HEADERS are from the web-push-lib.js file as you've suggested.
[
{
"message":"sent",
"title":"'title'",
"body":"'body'",
"icon":"'icon'",
"href":"'href'",
"tag":"'tag'",
"res":[
"HEADERS { hostname: 'android.googleapis.com',",
" port: null,",
" path: '/gcm/send/c7qnskTew5w:[redacted]',",
" headers:",
" { TTL: 7200,",
" 'Content-Length': 440,",
" 'Content-Type': 'application/octet-stream',",
" 'Content-Encoding': 'aesgcm',",
" Encryption: 'salt=[redacted]',",
" 'Crypto-Key': 'dh=[redacted]',",
" Authorization: 'key=[redacted]' },",
" method: 'POST' }",
{
"statusCode":201,
"body":"",
"headers":{
"content-type":"text/plain",
"location":"https://android.googleapis.com/gcm/0:[redacted]",
"date":"Fri, 30 Jun 2017 08:15:32 GMT",
"expires":"Fri, 30 Jun 2017 08:15:32 GMT",
"cache-control":"private, max-age=0",
"x-content-type-options":"nosniff",
"x-frame-options":"SAMEORIGIN",
"x-xss-protection":"1; mode=block",
"content-length":"0",
"server":"GSE",
"alt-svc":"quic=:443; ma=2592000; v=39,38,37,36,35",
"connection":"close"
}
}
]
}
]
This header here suggests that maybe there's a TTL of 30 days? "alt-svc":"quic=:443; ma=2592000; v=39,38,37,36,35",
hey all, i'm also seeing issues with this! have you guys got any example scenarios of when this is failing? did anyone file a bug yet @sathio ?? if not, i will!
I am also seeing issues with the TTL across different browsers (Chrome 76/75, Firefox 67/66) now. @marco-c / @gauntface Do you think this is a Chrome issue as this is being observed in the Firefox browser as well? @jacklbraze did you file a bug on this? If yes, can you link it here?
I contacted the FCM team as well regarding this issue, FCM Support team has acknowledged that they are aware of this issue and are working on a fix for it. And so I think we can close this ticket.
More details here
In reference to https://github.com/web-push-libs/web-push/issues/491 which is a duplicate of this, I wish to point that the fact that a value of ZERO for TTL in options object not being honoured is due to this line of code. This if condition will always fail for a ZERO TTL and fallback to the DEFAULT_TTL of 4 weeks.
https://github.com/web-push-libs/web-push/blob/7bda588ba056d1d568be8c3d60b112e7ea591b34/src/web-push-lib.js#L158
Request you to explain if this is expected behaviour.
