Support specifying which schemes should be output in swagger.json

[johanbrandhorst]

It is not possible to modify what the "schemes" list will contain when output from protoc-gen-swagger, as per

Schemes:     []string{"http", "https"},

(https://github.com/gengo/grpc-gateway/blob/03164ec50aaf90b115daec838d3ce18f4b0a34ea/protoc-gen-swagger/genswagger/template.go#L432).

This means that on HTTPS only servers, the swagger "Try it out!" buttons will attempt to use HTTP, and thus fail. Currently the workaround is to edit the output of protoc-gen-swagger to remove HTTP from the schemes list.

I'm not sure what would be the best way to fix this, but I would like some kind of way to configured the schemes at "compile time", without having to edit the output.

swagger-api/swagger-ui#1006 describes my problem.

[edrex]

I hit this too.

Reversing the order ("https" before "http") seems to be sufficient to cause swagger-ui to make https requests, so that might be a quick fix.

Is running grpc-gateway without HTTPS even supported?

[achew22]

There is no need for it to be specified as https. It could be specified as http. You can edit the swagger output file by hand and serve it with that line saying just "http" if you don't want to bother to modify the protoc-gen-swagger binary.

[edrex]

@achew22 I don't really understand your comment. In our config grpc-gateway is served under https only, so ideally for us schemes would just have one item, "https".

Are there people running it http-only, for whom changing the order would break the swagger "try it out" buttons?

[edrex]

I realized there is another option, just dropping the "schemes" key. If it's missing it defaults to the scheme the UI is being served from.

https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#schema

[edrex]

Agree with @achew22's thinking this is a bug in swagger-ui. Filed swagger-api/swagger-ui#2342.

[c4milo]

Yeah, it seems to be a bug in swagger-js swagger-api/swagger-js#841

[achew22]

swagger-api/swagger-js#841 is now closed. Closing this issue with the assumption that is fixed. If that's not the case please feel free to reopen the issue.