search

OAI / OpenAPI-Specification

The OpenAPI Specification Repository
https://openapis.org
Apache License 2.0
29k stars 9.07k forks source link

Disallow ? in path #468

Closed mohsen1 closed 9 months ago

mohsen1 commented 9 years ago

Schema should not allow path parameters abused as query parameter like this:

  /Login?UserID={id}&Token={token}:

See real world example here: http://stackoverflow.com/a/32658501/650722

dilipkrish commented 9 years ago

I think this is an implied assumption that query string params never surface to the path. There isn't something in the spec that prevents you from doing it. Thats the crux l of th problem in the SO post, that u should be able to distinguish diff paths based on query parameters. If we are to support that and consequently rfc 6570 (uri templates) this should absolutely be present.

webron commented 9 years ago

The spec definitely doesn't allow it. If it needs to be more explicit in the document, I'll make sure to make it clearer.

While some cases should not be checked by the schema, I believe this should be handled by the schema and will be fixed.

mohsen1 commented 9 years ago

It would be rare if someone puts fragments in path but we should disallow that by not allowing # character in path name also.

dilipkrish commented 9 years ago

I know we spoke about this, but what's the reason for the pushback? Is this not in consideration for the spec vNext?

webron commented 9 years ago

It is a consideration for the next version, but it's not in the current one, and the schema represents the current version. :)

@mohsen1 - I get your concern, but I'd rather limit for now ? and not fragments, based on how common these issues are. Perhaps in the future, if we see it becoming an issue, we would disallow fragments as well.

mohsen1 commented 9 years ago

Ron, if it's not a big change, please add # before we see it's abused. :)

handrews commented 9 months ago

The spec definitely disallows it. For validation in the schema, that would be handled by tagging it with an appropriate format that enforces the right rules for OAS URL templating, which is being discussed in several places:

I'm going to close this issue in favor of those. While format does not guarantee JSON Schema implementations will do the validation correctly, it is the best available option, and is consistent with how we handle other complex strings in the schema.