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

Image response always uses file serving #1652

Closed
barneaoren opened this issue Oct 7, 2015 · 8 comments
Closed

Image response always uses file serving #1652

barneaoren opened this issue Oct 7, 2015 · 8 comments

Comments

@barneaoren
Copy link

I have a POST request with accept = "image/jpeg" sent to the server on the path "/action"
The server processed the request and responded with Content-Type: image/jpeg and the data of the image.

The swagger-ui, as it seems, tries to show the image from "/action" via a new file serving (GET request) instead of the image of the data, which means that it thinks that the server supports file serving that way on this path.

It is important to mention the the path "/action" also supports a GET request for other purpose.

So to conclude this issue, the POST request returns the image data, which the swagger-ui won't even try to use.

@dgreenbean
Copy link

Something like this will probably fix this issue:
https://github.com/swagger-api/swagger-ui/compare/master...dgreenbean:feature/blob?expand=1

This change is just a hacky example. It will need some work to integrate correctly.

@glederrey
Copy link

@dgreenbean Hi,
I'm trying to use your hack.. But it doesn't work.. I put a screenshot of what I got when I'm using your hack (in Firefox).. Do you have an idea why I get this error?? Thank you

screenshot from 2016-01-21 17 12 38

@dgreenbean
Copy link

I wrote that hack a while ago. Swagger-ui has probably been updated since. Specifically, this hack deals with requests sent through jQuery, not superagent. If your requests are going through superagent, they will need a similar hack. Also, my example assumes the response type is "file" in the Swagger spec. I have since found that using the Accept header of the request is probably more reliable.

With this issue, my hope is to spark the discussion around what needs to be done for swagger-ui to actually support image, PDF and binary file outputs. While I primarily care about POST requests, the double-retrieve of GET requests is a little annoying.

@fehguy
Copy link
Contributor

fehguy commented Jan 21, 2016

It'd be trivial to update swagger-ui to require JQuery when downloading an image.

@dgreenbean
Copy link

There's nothing inherently wrong with superagent. Really, both modes
should support these outputs. When I get some time, I'll try to find the
right way to propose the changes to swagger-ui.

2016-01-21 18:27 GMT-05:00 Tony Tam notifications@github.com:

It'd be trivial to update swagger-ui to require JQuery when downloading an
image.


Reply to this email directly or view it on GitHub
#1652 (comment)
.

@fehguy
Copy link
Contributor

fehguy commented Jan 21, 2016

I agree, but jquery does have some advantages for the UI stuff. We use it for file uploads in the ui

@glederrey
Copy link

Hi,
@dgreenbean: I tried your hack with your code and also I tried to implement your hack to the new version of Swagger UI.. Sadly, both did not worked.. Same problem with this blob..

As you said, there is this double GET method to retrieve a file.. It's a bit annoying, but it works.. The real problem is with a POST method as it's doing a GET method after the POST method on the POST endpoint.. Therefore, you always get a 405 code..

@fehguy @dgreenbean : Do you think there's a simple hack to get rid of this problem?? Sadly, I'm not really good with JavaScript and I can't find a solution to this problem..

Thanks for your answer..

@webron
Copy link
Contributor

webron commented Jun 9, 2017

This should not be an issue in the new UI.

@webron webron closed this as completed Jun 9, 2017
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

5 participants