Non-nullable/non-allowEmptyValue optional query parameters being sent in requests

[mlieberman85]

If you don't provide values to optional query fields it still sends the optional fields as query parameters in the request. This leads to requests like: https://foo/bar?baz where if baz is not-nullable or have allowEmptyValue set many servers will reject it. An example openapi snippet:

  /bar:
    get:
      summary: Get bar
      operationId: getBar
      parameters:
        - name: baz
          in: query
          schema:
            type: integer
            format: int64

If needed, I can provide a more complete example. Also, I might be misunderstanding the intended behavior in openapi, so I could be wrong but it's based on my reading of: https://swagger.io/docs/specification/describing-parameters/

Empty-Valued and Nullable Parameters Query string parameters may only have a name and no value, like so: GET /foo?metadata Use allowEmptyValue to describe such parameters: parameters:

• in: query name: metadata schema: type: boolean allowEmptyValue: true # <----- OpenAPI 3.0 also supports nullable in schemas, allowing operation parameters to have the null value. For example, the following schema corresponds to int? in C# and java.lang.Integer in Java: schema: type: integer format: int32 nullable: true Note: nullable is not the same as an optional parameter or an empty-valued parameter. nullable means the parameter value can be null. Specific implementations may choose to map an absent or empty-valued parameter to null, but strictly speaking these are not the same thing.

[zaghaghi]

Thanks @mlieberman85 for reporting the issue. It's fixed now in 0.9.3 and pre-built binaries are available in release page and docker image will be available soon.