Swagger-ui: Try It out not working when two parameters of different type have the same name

[rubenmch]

If an operation has two parameters with the same name but different location (type), the Try It out button uses the same value for both parameters instead of sending each with its own value. It uses the value of the last parameter for both types.

The swagger 2 specification says:

A unique parameter is defined by a combination of a name and location.

We have an existing API that uses the query parameters to filter the data to be updated and the form parameters to assign the new values in a PUT operation.

How to reproduce:

1. Declare a PUT operation with the following Parameters:

yaml - name: Name in: query type: string - name: Name in: formData type: string

1. In Swagger UI fill the query Name parameter with the value QueryName
2. Fill the formData Name parameter with the value FormDataName
3. Click the Try It out! button

Result:

The formData and the query parameters will be sent with the value FormDataName

Expected result:

The query Name parameter is sent with the value QueryName
The formData Name parameter is sent with the value FormDataName

[pfrank13]

We're having this problem today on the latest swagger-ui 2.2.6, but with header parameters and query parameters with the same name. It seems arbitrary where the javascript client will actually put the value, and it's usually only the value of one of the * parameters. Is there any information I could provide further?

[daedeloth]

We're having the same problem with swagger-ui v2.1.4.

[webron]

While it's a bug, it's not going to be a high priority for a fix (PRs welcome). Keep in mind that in the next version of the spec, you will no longer be able to do that. Parameter names under an operation would have to be unique, regardless of the type.

[pfrank13]

@webron question about that, although I understand this is a corner case it's actually really common to use parameters in different parts of the HTTP request as overrides, an example, think something like an auth token, often that SHOULD be in a header but people will allow it in a query string to make it easier for linking internally. That won't straight out bork the swagger of the future will it? In my example, and the ones I'm concerned with, the proper behavior is to have parameters of the same name be mutually exclusive therefore this bug is avoided, however it would be sad if swagger became strict and flat out doesn't allow that sort of thing.

[webron]

Well, @pfrank13, you're in luck. You just caught me before we had a meeting on the next version of the spec, and I brought the issue back again.
We've agreed to keep the status of it as it is in 2.0 - that is, the name uniqueness depends on the location as well.

[pfrank13]

Fantastic news, thanks @webron

[webron]

Closing as duplicate of #828.