Q&A (please complete the following information)
- OS: macOS / Linux
- Browser: Chrome / Chromium
- Method of installation: springdoc-openapi webjar
- Swagger-UI version: 5.28.0
- Swagger/OpenAPI version: OpenAPI 3.1
Content & configuration
Example Swagger/OpenAPI definition:
openapi: 3.1.0
paths:
/render:
post:
requestBody:
required: true
content:
application/xml:
schema:
type: string
responses:
"200":
description: PDF rendered successfully
content:
application/pdf:
schema:
type: string
format: binary
"413":
description: Request body too large
content:
application/problem+json:
schema:
type: object
properties:
type:
type: string
title:
type: string
status:
type: integer
detail:
type: string
instance:
type: string
Swagger-UI configuration options:
SwaggerUI({
showMutatedRequest: true
})
Describe the bug you're encountering
When using "Try it out" with a large XML request body, the backend correctly returns HTTP 413 with application/problem+json.
Instead of rendering the live response reliably, Swagger UI can show:
😱 Could not render responses_Responses, see the console.
The response itself is valid. The failure appears to happen in Swagger UI's live response rendering path, where the sent request body is rendered again in the cURL/request display area.
To reproduce...
- Define an endpoint that accepts
application/xml request bodies.
- Return HTTP 413 with
application/problem+json when the request exceeds a server-side limit.
- Open the endpoint in Swagger UI.
- Click "Try it out".
- Paste/send a very large XML request body, e.g. several MB.
- Observe that the backend returns a valid 413 response.
- Swagger UI may render
Could not render responses_Responses instead of the response details.
Expected behavior
Swagger UI should render the 413 response body and headers normally.
If the request body is too large to safely render in the live response/cURL block, Swagger UI should truncate or virtualize only the displayed copy of the request body. The actual request sent to the server should remain unchanged.
Additional context or thoughts
We worked around this locally by truncating only the display copy of the request body used in the live response/cURL rendering path. The original request is still sent unchanged.
A possible upstream improvement would be a built-in display limit for request bodies in live response/cURL rendering, for example a configurable maxDisplayedRequestBodyChars, plus defensive handling when the mutated request is not available.
Q&A (please complete the following information)
Content & configuration
Example Swagger/OpenAPI definition:
Swagger-UI configuration options:
Describe the bug you're encountering
When using "Try it out" with a large XML request body, the backend correctly returns HTTP 413 with
application/problem+json.Instead of rendering the live response reliably, Swagger UI can show:
The response itself is valid. The failure appears to happen in Swagger UI's live response rendering path, where the sent request body is rendered again in the cURL/request display area.
To reproduce...
application/xmlrequest bodies.application/problem+jsonwhen the request exceeds a server-side limit.Could not render responses_Responsesinstead of the response details.Expected behavior
Swagger UI should render the 413 response body and headers normally.
If the request body is too large to safely render in the live response/cURL block, Swagger UI should truncate or virtualize only the displayed copy of the request body. The actual request sent to the server should remain unchanged.
Additional context or thoughts
We worked around this locally by truncating only the display copy of the request body used in the live response/cURL rendering path. The original request is still sent unchanged.
A possible upstream improvement would be a built-in display limit for request bodies in live response/cURL rendering, for example a configurable
maxDisplayedRequestBodyChars, plus defensive handling when the mutated request is not available.