Strengthen the schema w/r/t format, required fields #397
Conversation
will result in. It could be ascii, utf8, binary, etc.
This reverts commit d36c1ab.
Add fail tests for incomplete url or payload
bin/check_version
Outdated
| @@ -15,10 +15,14 @@ if [[ -z $origin ]]; then | |||
| origin=faucetsdn | |||
| fi | |||
|
|
|||
| git fetch $origin --tags 2>/dev/null | |||
| git fetch $origin --tags # 2>/dev/null | |||
schema/config_blobset_blob.json
Outdated
| }, | ||
| "sha256": { | ||
| "type": "string" | ||
| "type": "string", | ||
| "pattern": "^[0-9A-Za-z]{64}$" |
There was a problem hiding this comment.
what do you think about just making it all-lower or all-upper? Reason being, then it's easier to do a naive "string compare" to see if "hash matched" -- otherwise it takes extra code that somebody is likely to get wrong... I'd rather force the generation to be all-lower than rely on the equality check.
There was a problem hiding this comment.
I'm fine with all lowercase because that's customary. I was wondering if device makers would have other opinions, especially from non-Unix platforms.
There was a problem hiding this comment.
Also this is a mistake and it should be a-f not a-z.
| } | ||
| }, | ||
| "oneOf": [ | ||
| { "required": ["content_type", "base64"] }, |
There was a problem hiding this comment.
I would have expected oneOf { base64, url } (transport mechanism), and then sha256 is always required, and then content_type is optional? I suppose sha256 isn't required with base64... But doesn't content_type potentially apply to all transport mechanisms? Oh wait, is it because content_type is included in the HTTP response?
There was a problem hiding this comment.
Yes, content_type comes from http so we don't want to allow overriding it--feels dangerous to me
No description provided.