Swagger-ui does not use the right produces consumes application/json

[danjor]

I'm using the last version of swagger ui and I'm facing the following issue.
When no "host" attribute is defined in yaml, "produces" and "consumes" attributes are not used.

Indeed, with

consumes:
  - application/json
produces:
  - application/json

When I try executing a request, I get

curl -X GET --header 'Accept: text/html' 'http://myapi/X'

instead of

curl -X GET --header 'Accept: application/json' --header 'Content-Type: application/json' 'http://myapi/X'

Then analysing with the Chrome dev tools, Swagger-ui effectively sends a request with the wrong header containing wrong Accept and Content-Type (text/html), and my generated SpringMVC backend responds with an error 415 : "server can't produce text/html"

Why this behavior is happening ?

[webron]

You may have hit a bug here. To help us test it more quickly, can you provide with a minimal spec that reproduces the behavior?

[pqrkchqps]

I believe I have the same problem. I added the pem package and openssl to allow the server to work over https.

The error I get from the console is:
server can't produce text/html

Curl starts out with:
curl -X POST --header 'Content-Type: application/json' --header 'Accept: text/html' --header 'Content-type: application/json' --header 'domain-model: UpdateApplicationCommand' --header 'version: v0.0.1' -d '{

I put both the swagger file and the modified index.js file in a zip.
minspec.zip

Thanks

[jlh424]

I am having a similar issue. Any update?

[benoitmasson]

+1

When performing a GET request, Swagger UI does not take into account the consumes parameter, and does not set a Content-type header field.

With POST or PUT requests, it works.

[fehguy]

@benoitmasson, this is because the Content-Type header is optional (and typically problematic) when calling GET operations. Why? Because you can't pass a payload (which is what Content-Type defines) in a GET method, period. The Accepts header will tell the server what you want as a response format.

[fehguy]

@danjor please try from the latest master--I cannot reproduce this issue. With this simplified spec:

{
  "swagger": "2.0",
  "info": {
    "description": "This is a sample server Petstore server.  You can find out more about Swagger at <a href=\"http://swagger.io\">http://swagger.io</a> or on irc.freenode.net, #swagger.  For this sample, you can use the api key \"special-key\" to test the authorization filters",
    "version": "1.0.0",
    "title": "Swagger Petstore",
    "termsOfService": "http://swagger.io/terms/",
    "contact": {
      "name": "apiteam@swagger.io"
    },
    "license": {
      "name": "Apache 2.0",
      "url": "http://www.apache.org/licenses/LICENSE-2.0.html"
    }
  },
  "basePath": "/v2/api",
  "schemes": [
    "http"
  ],
  "produces": [
    "application/xml"
  ],
  "paths": {
    "/pet/{petId}": {
      "get": {
        "tags": [
          "pet"
        ],
        "summary": "Find pet by ID",
        "description": "Returns a pet when ID < 10.  ID > 10 or nonintegers will simulate API error conditions",
        "operationId": "getPetById",
        "parameters": [
          {
            "name": "petId",
            "in": "path",
            "description": "ID of pet that needs to be fetched",
            "required": true,
            "type": "integer",
            "format": "int64"
          }
        ],
        "responses": {
          "404": {
            "description": "Pet not found"
          },
          "200": {
            "description": "successful operation",
            "schema": {
              "$ref": "#/definitions/Pet"
            }
          },
          "400": {
            "description": "Invalid ID supplied"
          }
        },
        "security": [
          {
            "api_key": []
          },
          {
            "petstore_auth": [
              "write:pets",
              "read:pets"
            ]
          }
        ]
      }
    }
  },
  "definitions": {
    "Category": {
      "properties": {
        "id": {
          "type": "integer",
          "format": "int64"
        },
        "name": {
          "type": "string"
        }
      },
      "xml": {
        "name": "Category"
      }
    },
    "Pet": {
      "required": [
        "name",
        "photoUrls"
      ],
      "properties": {
        "id": {
          "type": "integer",
          "format": "int64"
        },
        "category": {
          "$ref": "http://petstore.swagger.io/v2/swagger.json#/definitions/Category"
        },
        "name": {
          "type": "string",
          "example": "doggie"
        },
        "photoUrls": {
          "type": "array",
          "xml": {
            "name": "photoUrl",
            "wrapped": true
          },
          "items": {
            "type": "string"
          }
        },
        "tags": {
          "type": "array",
          "xml": {
            "name": "tag",
            "wrapped": true
          },
          "items": {
            "$ref": "http://petstore.swagger.io/v2/swagger.json#/definitions/Tag"
          }
        },
        "status": {
          "type": "string",
          "description": "pet status in the store"
        }
      },
      "xml": {
        "name": "Pet"
      }
    },
    "Tag": {
      "properties": {
        "id": {
          "type": "integer",
          "format": "int64"
        },
        "name": {
          "type": "string"
        }
      },
      "xml": {
        "name": "Tag"
      }
    }
  }
}

I see the correct headers being sent to the server (intentionally set to xml to avoid the default content types):

Reopen if you still have this issue.