Closed Bug 1219850 Opened 4 years ago Closed 4 years ago

404 on POSTing to valid push device token


(Core :: DOM: Push Notifications, defect, P1)

44 Branch





(Reporter: casey, Unassigned)


User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.71 Safari/537.36

Steps to reproduce:

Registered a service worker. 
Requested notification permissions.
Received a device token. 
POSTed to device token URL to initiate a push. 

(I have run through this with the exact same code on a different machine and did not repro the issue, but these are the steps I took)

Exact code:

If pushing the button send a push, then it's all good. 

Actual results:

curl -X POST ""

{"errno": 106, "message": "No such subscription", "code": 404, "error": "Not Found"}

Expected results:

A 201 Created was expected.
Priority: -- → P1
106 means that the subscription has become invalid. (A 'subscription' is associated with a specific endpoint.) A subscription may become invalid if it receives too many messages without the user visiting the corresponding site, revoke the notification permission, or if the subscription has been "unsubscribed" by the user.

Sites do enforce a quota on the number of push messages that can be displayed without the user visiting a site. If you're sending these via Curl and not clicking on the notifications to visit the site, you may be running up against the quota and the subscription may become invalid. 

Do any of these seem to apply?
Flags: needinfo?(casey)
There wouldn't have been many messages.  But, I didn't realize it when filing but this reg was created a while ago: 2015-09-01 19:21:31.612Z

Might have been some activity that triggered the invalidity as not much was working on 9/1, so that could definitely explain it.  

As a user is there a way I can get out of this state and/or force the generation of a new token?  Tried enabling/disabling, visiting site, etc all to no avail.  

Would also be nice to have a user-visible indication or console log that it has been disabled as people will fall into this state (many site owners sub to their own site but don't click notes).
Flags: needinfo?(casey)
Sorry for all the hoops we've made you jump through, Casey. Thanks for being patient with us. We should drop the push subscription when you unregister the service worker, but that's not implemented yet (bug 1185716, if you'd like to follow along). For now, either the page or service worker needs to explicitly call `pushSubscription.unregister()`.

In Nightly, you can also reset all your subscriptions by clearing the `dom.push.userAgentID` pref in about:config.
Thanks for that Kit! 

Still a bit worried about what the experience will be for end-users who quota-out though.  What do you think about just fully unregistering them from the perspective of the browser?  They'd get re-prompted on next visit which would re-enable things through the whole chain (serviceworker, server, etc).
Component: Untriaged → Notifications and Alerts
Product: Firefox → Toolkit
If the quota is exceeded, we currently fire a `pushsubscriptionchange` event, either on the next idle timer (~1 day, same as the service worker update interval), or when Firefox is restarted.

We've documented this as "the worker can request a new subscription when the user visits the site again," but that's not quite true. Even if the user visits the site again, the service worker won't find out until the event is fired. We may want to revisit this.

Also, we're relaxing the quota in bug 1210211. The new behavior is to wait 3 seconds after a push message is received before recalculating the quota. If there's at least one visible notification for the site at the end of the 3 seconds, we won't dock you at all.
Component: Notifications and Alerts → DOM: Push Notifications
Product: Toolkit → Core
In addition to the quota, there was also a server-side bug that corrupted valid registrations. This was fixed in and deployed, so I'll go ahead and close this ticket out.
Closed: 4 years ago
Resolution: --- → FIXED
Facing the same issue was trying the curl

curl -i -X "TTL: 60" POST ""

Could not resolve host: POST
Content-Length: 0
Connection: Close

Is the link for push notification changed or something wrong with my curl can someone help
Try moving the "-X" one argument down, add a "-H", and it should work if the endpoint is valid. ("/push/" endpoints are older; if it's expired, you'll see a 404 or a 410). Like this:

curl -i -H "TTL: 60" -X POST ""
curl -i -H "TTL: 60" -X POST ""
Tried this  but still I am getting 404 error. The endpoint is not expired because I just created it.
HTTP/1.1 404 Not Found
Content-Type: text/html; charset=UTF-8
Date: Mon, 06 Feb 2017 18:17:15 GMT
Server: nginx
Content-Length: 69
Connection: keep-alive

<html><title>404: Not Found</title><body>404: Not Found</body></html>
Interesting! Two questions:

* Could you post the full endpoint, please? (With the full token, instead of "fireFoxEndPoint").
* How are you creating the endpoint? AFAIK, we're not issuing new "/push" endpoints to Firefox anymore. Are you using a custom client?
Cool, thanks! Those endpoints are different; "/wpush/v1" != "/push". :-) This returns a 201 for me:

curl -i -H "TTL: 60" -X POST
thank you it works fine, have few queries though.

1) are the endpoints "/wpush/v1" deprecated and replaced by "/push"
3) what's the difference between "/wpush/v1" and "/push" endpoints
2) how do i get "/push" endpoint
It's an implementation detail, so that our push server knows how to deliver the message. You can't get a specific endpoint; only the server controls that.

In general, though, you should assume the endpoint is opaque, and not try to parse it. In the future, we might issue endpoints like "" or "", or even "". It's not safe to assume that all Mozilla push endpoints start with "". They can and will change.
thanks for the info, will change the way it is saved on db and store the entire link instead of just endpoints.
Great, thank you!
You need to log in before you can comment on or make changes to this bug.