New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 871089 link

Starred by 1 user
Status: WontFix
Owner: ----
Closed: Sep 10
Cc:
█ krajshree@chromium.org
peter@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

Push Notifications either rejected or aren't passed to event listener

Reported by vi...@vihan.org, Aug 5 
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.84 Safari/537.36

Steps to reproduce the problem:
1. Obtain permissions to display notifications
2. Register service worker
3. Subscribe to push service with public key
4. Client sends the subscription JSON to my server
5. Server attempts to send push notification gets 400 InvalidParameters error
6. Attempt to send notification from chrome dev tools using "Push" button also results in the push callback never being called

What is the expected behavior?
The same codebase works fine on firefox which makes it unusual to me why chrome would give 400 on push. Additionally neither the service worker, the original script, or the server throws an error. All DB entries for the endpoint/auth/p256dh values are correct.

What went wrong?
Not sure specifically how the "Push" button on chrome is implemented however I'm not sure why both the Push button on dev tools and my server are both not working. The service worker is very minimal and works fine on Firefox which is unusual

Did this work before? No 

Does this work in other browsers? Yes

Chrome version: 68.0.3440.84  Channel: stable
OS Version: OS X 10.13.4
Flash Version: 

I've uploaded the request that my server is sending too. The response from googleapis is just "InvalidParameters Error 400" and the documentation online says this means "an invalid header" but I've implemented webpush according to the google's webpush docs and again, mozilla correctly returns 201 with the same code/payload.
PushNotifications.js
270 bytes View Download
request.txt
841 bytes View Download

Comment 1 by anfatsal...@gmail.com, Aug 5

regist.text
102 bytes Download

Comment 2 by vamshi.kommuri@chromium.org, Aug 6

Labels: Needs-Triage-M68

Comment 3 by vi...@vihan.org, Aug 6 

Looks like Chrome returns 400 on a push if there is padding in the base64 for the Crypto-Key/Authorization headers.

Comment 4 by krajshree@chromium.org, Aug 8

Cc: krajshree@chromium.org
Labels: Triaged-ET Needs-Feedback
vihan@ - Thanks for filing the issue...!!

Would it be possible to attach a sample html page or test url to test the issue for ease of reproduction and check whether this has regressed in chrome or not. This will help us in triaging the issue further from TE-end.

Thanks...!!

Comment 5 by ellyjo...@chromium.org, Sep 10

Status: Untriaged (was: Unconfirmed)
Mac triage: marking this for Blink>PushAPI triage. I don't think we need a more detailed repro case in light of #3.

Comment 6 by peter@chromium.org, Sep 10

Status: WontFix (was: Untriaged)
> Looks like Chrome returns 400 on a push if there is padding in the base64 for the Crypto-Key/Authorization headers

The values in those headers use URL-safe base64, which explicitly disallow padding. Please remove it before you send it to the push service.

On a tangent, consider updating to RFC8291, which is the final payload format that's recommended going forward :).

https://tools.ietf.org/html/rfc8291
►

Sign in to add a comment