Skip to content

Commit ffe0434

Browse files
committed
Rework the guidance around fragmentary parsing.
This goes into more detail and uses "undefined" instead of "implementation-defined" as the behavior is likely to be incorrect (rather than just a different interpretationof an ambiguous requirement), and may result in security concerns as well.
1 parent 3f60c51 commit ffe0434

File tree

1 file changed

+10
-1
lines changed

1 file changed

+10
-1
lines changed

versions/3.1.1.md

Lines changed: 10 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -154,7 +154,16 @@ Implementations MAY support complete-document parsing in any of the following wa
154154
* Detecting a document containing a referenceable Object at its root based on the expected type of the reference
155155
* Allowing users to configure the type of documents that might be loaded due to a reference to a non-root Object
156156

157-
Embedding fragments of OpenAPI content in other formats can produce unexpected interactions among the enclosing format, the OAS, and JSON Schema. While implementations MAY choose to support such arrangements, the resulting behavior is _implementation defined_. This includes parsing fragments of OpenAPI out of a complete OpenAPI document while treating the rest of the document as arbitrary JSON or YAML. Since parsing isolated fragments in this way will fail to notice keywords that might impact meaning or behavior, including in ways that contradict this specification's requirements, it is RECOMMENDED that OpenAPI Description authors avoid depending on such behavior.
157+
Implementations that parse referenced fragments of OpenAPI content without regard for the content of the rest of the containing document will miss keywords that change the meaning and behavior of the reference target.
158+
In particular, failing to take into account keywords that change the base URI introduces security risks by causing references to resolve to unintended URIs, with unpredictable results.
159+
While some implementations support this sort of parsing due to the requirements of past versions of this specification, in version 3.1, the result of parsing fragments in isolation is _undefined_ and likely to contradict the requirements of this specification.
160+
161+
While it is possible to structure certain OpenAPI Descriptions to ensure that they will behave correctly when references are parsed as isolated fragments, depending on this is NOT RECOMMENDED.
162+
This specification does not explicitly enumerate the conditions under which such behavior is safe, and provides no guarantee for continued safety in any future versions of the OAS.
163+
164+
A special case of parsing fragments of OAS content would be if such fragments are embedded in another format, referred to as an _embedding format_ with respect to the OAS.
165+
Note that the OAS itself is an embedding format with respect to JSON Schema, which is embedded as Schema Objects.
166+
It is the responsibility of an embedding format to define how to parse embedded content, and OAS implementations that do not document support for an embedding format cannot be expected to parse embedded OAS content correctly.
158167

159168
#### <a name="structuralInteroperability"></a>Structural Interoperability
160169

0 commit comments

Comments
 (0)