Chromium Code Reviews Chromium Code Reviews
Issue
22992006:
WebCrypto: Add exception messages for algorithm normalization failures. (Closed)
DescriptionWebCrypto: Add exception messages for algorithm normalization failures.
----------
Overview
----------
There are many problems that can occur during algorithm normalization, and they all have the same exception type (TypeError).
Without a good exception description, it is difficult for users of the API to know what went wrong (I have been experiencing this very problem while writing layout tests)
This change additionally enforces the range on numeric parameters (i.e. [EnforceRange]), which was previously a FIXME. This behavior isn't part of the WebCrypto spec yet, however it will be in a future update (https://www.w3.org/Bugs/Public/show_bug.cgi?id=23017).
----------
Examples
----------
Here are some examples of the new exception messages:
(1) "Algorithm: AES-CBC: AesCbcParams: iv: Missing or not a ArrayBufferView"
(Meaning: Didn't specify the iv parameter for AES-CBC. Users can see what is expected by looking at the "AesCbcParams" dictionary in the specification)
(2) "Algorithm: HMAC: HmacParams: hash: Missing or not a dictionary."
(Meaning: Didn't specify the hash attribute for an HMAC Algorithm. Users can see what is expected by looking at the HmacParams dictionary in the specification)
(3) "Algorithm: HMAC: HmacParams: hash: Algorithm: name: Missing or not a string."
(Meaning: Didn't specify "hash.name" for an HMAC Algorithm)
(4) "Algorithm: HMAC: HmacParams: hash: Algorithm: Unrecognized algorithm name."
(Meaning: specified hash.name, however it didn't identify a registered algorithm).
(5) "Algorithm: HMAC: HmacParams: hash: Algorithm: AES-CBC: Unsupported operation."
(Meaning: the "hash" specified for HMAC was AES-CBC, which is NOT a valid digest. This error message would be better if it said: "Does not support digest". I will re-visit that in a follow-up CL, since it requires some extra work)
----------
Implementation
----------
The implementation works by keeping a stack of string literals which describe the context of the error. A stack works better than an individual string, since algorithm identifiers can be nested and property names alone are ambiguous.
There is very little overhead to keeping track of the context while parsing algorithm identifiers, since string literals are cheap to push into a stack (no extra allocations). A final string is constructed only on failure by joining all the literals in the stack with ": ".
BUG=245025
R=abarth@chromium.org
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=156533
Patch Set 1 : #Patch Set 2 : Add a comment to explain inline size of Vector #
Total comments: 2
Patch Set 3 : Remove unnecessary comments #Patch Set 4 : rebase onto master #Patch Set 5 : Replace INFINITY with std::isinf() an NAN with std::isnan() to make it work on windows #Patch Set 6 : Use trunc() #
Messages
Total messages: 11 (0 generated)
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
