Unrecognized response type - application/pdf displayed incorrectly in response body

[fabieu]

Q&A

• Method of installation: dist
• Swagger-UI version: e.g. 3.23.0
• Swagger/OpenAPI version: OpenAPI 3.0

Content & configuration

Swagger/OpenAPI definition:

  /pdf/{date}/lunch.pdf:
    get:
      tags:
        - PDF
      summary: Mittagessen als PDF (Woche)
      parameters:
        - name: date
          in: path
          description: YYYY-MM-DD
          required: true
          schema:
            type: string
      responses:
        '200':
          description: OK
          headers:
            Content-Disposition:
              schema:
                type: string
                example: filename=\lunch.pdf\
          content:
            application/pdf:
              schema:
                type: string
                format: binary
              example: PDF-Datei

Describe the bug you're encountering

When you are calling an API in the try it out-section which returns an PDF-File the response body is not able to render the file or present it in a readable format. Instead you get the following message: Unrecognized response type; displaying content as text. - even if the correct content type is passed in the response header. Additionally the binary data will be displayed in the response body.

To reproduce...

Steps to reproduce the behavior: In Swagger-UI

1. Navigate to the specific path
2. Click on 'Try it out'
3. 'Execute'
4. Inspect Response body

Expected behavior

The PDF should be rendered as an typical pdf file in the swagger-ui or you should provide a download link to extract the file.

Screenshots

HTTP Request-Response Swagger-UI Display

Additional context or thoughts

Unfortunatly i cannot provide a running API which returns a valid PDF-File to debugging this issue Whenever you run the command curl -X GET "http://server.de/menupdfservice/api/pdf/pdf/2019-07-26/lunch.pdf" -H "accept: application/json which the Swagger-UI is calling outside of Swagger-UI you get the binary data as well. But when you try to merge this data with curl -X GET "http://server.de/menupdfservice/api/pdf/pdf/2019-07-26/lunch.pdf" -H "accept: application/json --output lunch.pdf in a spefic file with extension you get a properly working PDF-file

[a-a-k]

@fabieu have you solved that?

[fabieu]

@fabieu have you solved that?

Actually not, but I was tired dealing with this issue

[Pzixel]

Same here. I'm using swagger-jsdoc and face this issue. My endpoint:

/**
 * @swagger
 *
 * /pdf:
 *   post:
 *     description: Get PDF
 *     produces:
 *       - application/pdf
 *     parameters:
 *       - in: body
 *         name: orderIds
 *         description: order ids 
 *         schema:
 *           type: array
 *           items:
 *             type: string
 *             format: guid
 *     responses:
 *       200:
 *         description: A PDF file
 *         content:
 *           application/pdf:
 *             schema:
 *               type: file
 *               format: binary
 */

[Pzixel]

In the end it worked when I added headers to the response:

res.setHeader('Content-Type', 'application/pdf');
res.setHeader('Content-Disposition', 'attachment; filename=labels.pdf');

[rs-renato]

Same problem here, and besides that, The serialized string has encoding issue. If I test from browser or JAVA client, the PDF response is correct.

Sounds to be an issue on swagger-ui to render/serialize PDF files,

[admalledd]

I don't have the tooling on-hand right now, but I wonder if it makes sense to extend the if-statement here to include /^application\/octet-stream/i.test(contentType) || /^application\/pdf/i.test(contentType) ...? response-body.jsx#L61

I have a situation where we need to prefer the user/browsers view the PDFs instead of directly downloading first. So having the header read content-disposition: inline; filename=SomeFile.pdf vs attachment is what we need. note that content-disposition: attachment; filename=SomeFile.pdf doesn't complain about the "Unrecognized Response Type" because it short-circuits into the "if" as an attachment/download.

A more-correct solution would be somehow in the "else" side of the statement where it checks for json, xml, images, etc, to check for PDF and do a inline-viewer magic (pdf.js? no preference from me, just "something")

[tesshsu]

Same issue for my side, Is anyone really solve issue by swagger doc side ? follow my endpoint : headers: Content-Disposition: schema: type: string example: filename=\invoice.pdf
content: application/pdf: schema: type: file format: binary example: invoice.pdf

[Dhairyavan]

I am having same issue in FastAPI where it works for attachment it gives download option for attachment but for inline I am getting message. Also I have noticed that inline giving me PDF file as an output for inline option as well as for attachment. It seems to be an issue with FastAPI Swagger UI

headers = {'Content-Disposition': 'inline; filename="out.pdf"'} #headers = {'Content-Disposition': 'attachment; filename="out.pdf"'} return Response((row[1]), headers=headers, media_type='application/pdf')

Unrecognized response type; displaying content as text.

%PDF-1.3 1 0 obj << /Count 1 /Kids [3 0 R] /MediaBox [0 0 595.28 841.89] /Type /Pages

endobj 2 0 obj << /OpenAction [3 0 R /FitH null] /PageLayout /OneColumn /Pages 1 0 R /Type /Catalog

endobj 3 0 obj << /Contents 4 0 R /Parent 1 0 R /Resources 6 0 R /Type /Page

endobj 4 0 obj << /Filter /FlateDecode /Length 74

stream x�3R��2�35W(�r Q�w3T04�30PISp �Z(����)��(hx����+���(j*�d��#M endstream endobj 5 0 obj << /BaseFont /Helvetica-Bold /Encoding /WinAnsiEncoding /Subtype /Type1 /Type /Font

endobj 6 0 obj << /Font <</F1 5 0 R>> /ProcSet [/PDF /Text /ImageB /ImageC /ImageI]

endobj 7 0 obj << /CreationDate (D:20230929150353Z15'03')

endobj xref 0 8 0000000000 65535 f 0000000009 00000 n 0000000096 00000 n 0000000199 00000 n 0000000279 00000 n 0000000424 00000 n 0000000526 00000 n 0000000613 00000 n trailer << /Size 8 /Root 2 0 R /Info 7 0 R /ID [<4527CC16A77C85F8369BA38DDA715212><4527CC16A77C85F8369BA38DDA715212>]

startxref 674 %%EOF