Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Both HTTP and HTTPS ports cannot be specified #214

Closed
prantlf opened this issue Nov 20, 2014 · 14 comments
Closed

Both HTTP and HTTPS ports cannot be specified #214

prantlf opened this issue Nov 20, 2014 · 14 comments

Comments

@prantlf
Copy link

prantlf commented Nov 20, 2014

I have an API exposed on custom ports:

http://server:8000/api
https://server:8443/api

When I test the API with https://editor.swagger.io, I can switch the protocol from HTTP to HTTPS on the page, but because the port is entered only once with the host together and used for both schemes, I cannot actually send the request to the correct HTTPS endpoint:

host: server:8000
basePath: /api
schemes:
  - http
  - https

Why not adding an additional property configuring the HTTP and HTTPS ports?

@webron
Copy link
Member

webron commented Nov 20, 2014

That's a good point.

@earth2marsh
Copy link
Member

👍

@mohsen1
Copy link
Contributor

mohsen1 commented Mar 10, 2015

My opinion:

We should make it possible to provide a list of hosts. Swagger should not be deterministic which host should be used for which scheme.

@fehguy
Copy link
Contributor

fehguy commented Mar 10, 2015

Is it unreasonable to expect that https is always 443?

@webron
Copy link
Member

webron commented Mar 10, 2015

Yes. The OP.

@casualjim
Copy link
Contributor

I'm all for scheme: port type of mapping

while swagger assumes it's http there is also wss in there and soon there is server push and so on with http2.
Now there is no reason why somebody couldn't expose the swagger api over a rabbitmq messsage bus or some zeromq interface which supports these messaging paradigms.

the host can be assumed to be the same but a scheme represents more often than not a port.

@olensmar
Copy link

I agree - I think it would be insanely cool (almost) if one could open up for using swagger to describe APIs exposed over other protocols than HTTP(s) - (I'm primarily thinking CoAP, MQTT, WebSockets)

@webron
Copy link
Member

webron commented Mar 10, 2015

And pigeons.

@fehguy
Copy link
Contributor

fehguy commented Mar 10, 2015

@olensmar have you seen this project?

https://github.com/swagger-api/swagger-socket

Unbelievable potential with this.

@ndhar-1
Copy link

ndhar-1 commented Jun 18, 2015

Just out of curiosity, when you say you want to expose the APIs on both http and https, you intend to accept both secured and unsecured connections? I think it defeats the purpose of having security ... ?

@prantlf
Copy link
Author

prantlf commented Jul 31, 2015

Well, discussing security is out of the scope of this issue, isn't it? :-)

I can't know for what purpose is the API on the p[articular port used, how the connection is allowed the access to and how it is secured. All I deal with is that the server offers both schemes. I can either document and test both of them with Swagger, or I can use only one there.

I agree that unless more details are given, using https is a "must" for the usual REST API security.

@webron
Copy link
Member

webron commented Mar 27, 2016

Parent: #560.

This was referenced Apr 8, 2016
@fehguy fehguy closed this as completed Apr 14, 2016
@fmvilas
Copy link

fmvilas commented May 16, 2017

@olensmar you might be interested in the AsyncAPI specification: asyncapi.com.

@SergioArrighi
Copy link

SergioArrighi commented Jul 3, 2017

+1
I want to serve some calls on http and other on https. I'm testing my API locally with swagger UI and as host I configured localhost:8080. When I select HTTPS, calls are still sent to 8080. I don't understand how this is supposed to be working. Would swagger UI switch back to default 80 443 if I omit port in host configuration?
Regards

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants