Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disallow even optional "content*" processing #1296

Merged
merged 3 commits into from
Oct 17, 2022
Merged

Disallow even optional "content*" processing #1296

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
e59dc7a
Disallow even optional "content*" processing
handrews Sep 19, 2022
2a2f983
Fix duplicated word
handrews Sep 22, 2022
e7d36b2
Remove confusing parenthetical aside
handrews Sep 26, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 6 additions & 26 deletions jsonschema-validation.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -936,42 +936,21 @@
<t>
Due to security and performance concerns, as well as the open-ended nature of
possible content types, implementations MUST NOT automatically decode, parse,
and/or validate the string contents by default. This additionally supports
the use case of embedded documents intended for processing by a different
consumer than that which processed the containing document.
and/or validate the string contents. Applications are expected to use these
annotations to invoke the appropriate libraries separately.
</t>
<t>
All keywords in this section apply only to strings, and have no
effect on other data types.
</t>
<t>
Implementations MAY offer the ability to decode, parse, and/or validate
the string contents automatically. However, it MUST NOT perform these
operations by default, and MUST provide the validation result of each
string-encoded document separately from the enclosing document. This
process SHOULD be equivalent to fully evaluating the instance against
the original schema, followed by using the annotations to decode, parse,
and/or validate each string-encoded document.
<cref>
For now, the exact mechanism of performing and returning parsed
data and/or validation results from such an automatic decoding, parsing,
and validating feature is left unspecified. Should such a feature
prove popular, it may be specified more thoroughly in a future draft.
</cref>
</t>
<t>
See also the <xref target="security">Security Considerations</xref>
sections for possible vulnerabilities introduced by automatically
processing the instance string according to these keywords.
</t>
</section>

<section title="contentEncoding">

<t>
If the instance value is a string, this property defines that the string
SHOULD be interpreted as encoded binary data and decoded using the encoding
named by this property.
SHOULD be interpreted as encoded binary data and applications wishing
to decode it SHOULD do so using the encoding named by this property.
</t>

<t>
Expand Down Expand Up @@ -1023,7 +1002,8 @@
</t>
<t>
This keyword MAY be used with any media type that can be mapped into
JSON Schema's data model.
JSON Schema's data model. Specifying such mappings is outside of the
scope of this specification.
</t>
<t>
The value of this property MUST be a valid JSON schema. It SHOULD be ignored if
Expand Down