Closed stevenatkin closed 6 years ago
The options
attribute is an instance of PushSubcriptionsOptionsInit
, which has the applicationServerKey
member that you're referring to. Our intent with the phrasing of 8.10.4. is to avoid repeating the individual members of PushSubscriptionOptions
.
When the developer passes a DOMString
, step 8.4.1. converts it to a BufferSource
, but we don't write it back to options
. That means that step 8.10.4. would still use the DOMString
, and would thus fail.
I'm not sure what the cleanest way of fixing this is. Changing 8.4. to the following may work?
- If the
applicationServerKey
is provided as aDOMString
, set its value to aBufferSource
containing the sequence of octets that result from decodingapplicationServerKey
using the base64url encoding [RFC7515]. If decoding fails, rejectpromise
with aDOMException
whose name is "InvalidCharacterError" and terminate these steps.- Ensure that the
applicationServerKey
describes a valid point on the P-256 curve. If theapplicationServerKey
value is invalid, reject promise with aDOMException
whose name is "InvalidAccessError" and terminate these steps.
What do you think, @martinthomson?
That would be fine. It means writing to options, which isn't ideal, but it's an elegant solution.
In step 10.4 it states that the option values need to be compared for equality. What type of equality checking is being performed? The options argument seems to be either a BufferSource or a DOMString. So are you using byte equality when it is a BufferSource vs. some other type of equality checking when it is a DOMString?