Disallow ? in path

[mohsen1]

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]

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]

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]

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

[dilipkrish]

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

[webron]

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]

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

[handrews]

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:

• Add templated-url format to the registry #3234
• Define formats for URL templating with and without runtime expressions #3530
• Drop uri-reference format for template URLs #3455

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.