[
https://issues.apache.org/jira/browse/SOLR-18504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-18504:
-------------------------------
Description:
The published OpenAPI document describes one URL twice, under two different
parameter names:
{code:java}
/{indexType}/{indexName}/schema/dynamicfields/{dynamicFieldName} DELETE, PUT
/{indexType}/{indexName}/schema/dynamicfields/{fieldName} GET
{code}
The OpenAPI Specification forbids this — "Templated paths with the same
hierarchy but different templated names MUST NOT exist, as they are identical"
— and the sibling endpoint is spelled correctly as a single entry:
{code}
{indexType}/{indexName}/schema/fields/{fieldName} carries
DELETE, GET and PUT together.
{code}
The cause appears to be two JAX-RS interfaces naming their {{@PathParam}}
differently for the same path, with the generator emitting both without
complaint.
h3. Consequence
Any consumer resolving a concrete URL against the document has to choose one of
the two entries, and first-match-wins is wrong for whichever verbs live in the
other. An editor built on this document reported "DELETE is not allowed on this
path — it takes GET" for a DELETE that works against a running 10.0.0; all
three verbs work in practice. Code generators are likely to produce two
colliding client methods, each missing the other's operations.
h3. Fix
Make the two {{@PathParam}} names agree so the paths merge into one entry with
all three verbs, and consider a build-time check that fails when two templates
collapse to the same shape after parameter-name erasure — the same mistake is
easy to repeat, and a scan of the whole document for other duplicates is worth
doing in the same pass.
was:
The published OpenAPI document describes one URL twice, under two different
parameter names:
{code:java}
/{indexType}/{indexName}/schema/dynamicfields/{dynamicFieldName} DELETE, PUT
/{indexType}/{indexName}/schema/dynamicfields/{fieldName} GET
{code}
The OpenAPI Specification forbids this — "Templated paths with the same
hierarchy but different templated names MUST NOT exist, as they are identical"
— and the sibling endpoint is spelled correctly as a single entry:
{{{indexType}/\{indexName}/schema/fields/\{fieldName}}} carries DELETE, GET and
PUT together.
The cause appears to be two JAX-RS interfaces naming their {{@PathParam}}
differently for the same path, with the generator emitting both without
complaint.
h3. Consequence
Any consumer resolving a concrete URL against the document has to choose one of
the two entries, and first-match-wins is wrong for whichever verbs live in the
other. An editor built on this document reported "DELETE is not allowed on this
path — it takes GET" for a DELETE that works against a running 10.0.0; all
three verbs work in practice. Code generators are likely to produce two
colliding client methods, each missing the other's operations.
h3. Fix
Make the two {{@PathParam}} names agree so the paths merge into one entry with
all three verbs, and consider a build-time check that fails when two templates
collapse to the same shape after parameter-name erasure — the same mistake is
easy to repeat, and a scan of the whole document for other duplicates is worth
doing in the same pass.
> OpenAPI document contains duplicate path templates for the dynamic-field
> endpoints
> ----------------------------------------------------------------------------------
>
> Key: SOLR-18504
> URL: https://issues.apache.org/jira/browse/SOLR-18504
> Project: Solr
> Issue Type: Bug
> Components: v2 API
> Affects Versions: 10.0
> Reporter: Jan Høydahl
> Assignee: Jan Høydahl
> Priority: Major
>
> The published OpenAPI document describes one URL twice, under two different
> parameter names:
> {code:java}
> /{indexType}/{indexName}/schema/dynamicfields/{dynamicFieldName} DELETE, PUT
> /{indexType}/{indexName}/schema/dynamicfields/{fieldName} GET
> {code}
> The OpenAPI Specification forbids this — "Templated paths with the same
> hierarchy but different templated names MUST NOT exist, as they are
> identical" — and the sibling endpoint is spelled correctly as a single entry:
> {code}
> {indexType}/{indexName}/schema/fields/{fieldName} carries
> DELETE, GET and PUT together.
> {code}
> The cause appears to be two JAX-RS interfaces naming their {{@PathParam}}
> differently for the same path, with the generator emitting both without
> complaint.
> h3. Consequence
> Any consumer resolving a concrete URL against the document has to choose one
> of the two entries, and first-match-wins is wrong for whichever verbs live in
> the other. An editor built on this document reported "DELETE is not allowed
> on this path — it takes GET" for a DELETE that works against a running
> 10.0.0; all three verbs work in practice. Code generators are likely to
> produce two colliding client methods, each missing the other's operations.
> h3. Fix
> Make the two {{@PathParam}} names agree so the paths merge into one entry
> with all three verbs, and consider a build-time check that fails when two
> templates collapse to the same shape after parameter-name erasure — the same
> mistake is easy to repeat, and a scan of the whole document for other
> duplicates is worth doing in the same pass.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
