Skip to content

Validate empty Swagger property names - #2343

Closed
king-407 wants to merge 2 commits into
swagger-api:masterfrom
king-407:issue-2339-empty-property-name-validation
Closed

Validate empty Swagger property names#2343
king-407 wants to merge 2 commits into
swagger-api:masterfrom
king-407:issue-2339-empty-property-name-validation

Conversation

@king-407

@king-407 king-407 commented Jun 9, 2026

Copy link
Copy Markdown

Fixes #2339.

What changed

This adds validation for Swagger 2.0 schemas that contain an empty property name under properties.

Previously, a schema like this was parsed without reporting a validation message:

"properties": {
  "AA": { "type": "string" },
  "": { "type": "number" }
}

The converter now adds a validation message for the empty property name while continuing to parse the document.

Testing

Ran the focused regression test and the full V2ConverterTest class:

mvn -pl modules/swagger-parser-v2-converter -am -Dtest=V2ConverterTest#testEmptyPropertyNameHasMessage -Dsurefire.failIfNoSpecifiedTests=false test
mvn -pl modules/swagger-parser-v2-converter -am -Dtest=V2ConverterTest -Dsurefire.failIfNoSpecifiedTests=false test

Signed-off-by: king-407 <95581750+king-407@users.noreply.github.com>
@king-407
king-407 marked this pull request as ready for review June 9, 2026 15:41
@ewaostrowska

Copy link
Copy Markdown
Contributor

Thanks for the fix and the regression test!
We looked at the relevant specs and don't think an empty key in properties is a Swagger 2.0 validation error.

The OpenAPI 2.0 Schema Object applies JSON Schema semantics to properties. JSON Schema Draft 4 requires properties to be an object where each value is a valid schema, but says nothing about the names being non-empty. The official OpenAPI 2.0 validation schema has no such restriction either.

Duplicate names are a separate problem. RFC 8259 recommends unique names and warns that behavior is unpredictable otherwise, but by the time SwaggerConverter receives a Map<String, Property>, duplicates have already been collapsed. A converter traversal can't reliably detect that data loss.

Emitting a warning here would flag spec-valid documents as broken and could cause consumers that treat parser messages as errors to reject those documents.

We're closing this without merging. Thanks again for digging into this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: Anonymous objects fail to report errors during parsing

3 participants