Skip to content

OpenAPI 3.1.0 support: GET request body support with OpenAPI 3.1, swagger-ui 5.X #8682

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

Closed
Nikit123 opened this issue May 18, 2023 · 1 comment

Comments

@Nikit123
Copy link

Nikit123 commented May 18, 2023

Q&A (please complete the following information)

  • OS: [macOS]
  • Browser: [chrome]
  • Version: [113.0]
  • Method of installation: [dist assets]
  • Swagger-UI version: [5.0.0-alpha.13]
  • Swagger/OpenAPI version: [OpenAPI 3.1]

How can we help?

I am using a GET api, where I need to send a request body. I took 5.0.0-alpha.13 distribution of swagger, as I saw that it is compatible with OpenAPI 3.1. Although, when I am running it with OpenAPI 3.1, and trying to execute my GET api I still get this error - 'TypeError: Failed to execute 'fetch' on 'Window': Request with GET/HEAD method cannot have body'.

My server handles the GET request body as I have tested it with Postman and I know that OpenAPI 3.1 supports request body with GET requests. Why is swagger-ui not allowing me to do the same? Am I missing something, or this support is not in place and planned for a future release?

@Nikit123 Nikit123 changed the title GET request body support with OpenAPI 3.1 GET request body support with OpenAPI 3.1, swagger-ui 5.X May 18, 2023
@char0n char0n changed the title GET request body support with OpenAPI 3.1, swagger-ui 5.X OpenAPI 3.1.0 support: GET request body support with OpenAPI 3.1, swagger-ui 5.X May 18, 2023
@char0n char0n self-assigned this May 18, 2023
@char0n
Copy link
Member

char0n commented May 18, 2023

Hi @Nikit123,

I am using a GET api, where I need to send a request body. I took 5.0.0-alpha.13 distribution of swagger, as I saw that it is compatible with OpenAPI 3.1

Yes, this is true

Although, when I am running it with OpenAPI 3.1, and trying to execute my GET api I still get this error - 'TypeError: Failed to execute 'fetch' on 'Window': Request with GET/HEAD method cannot have body'.

Yes, this is expected behavior. I'll explain further below.

My server handles the GET request body as I have tested it with Postman and I know that OpenAPI 3.1 supports request body with GET requests. Why is swagger-ui not allowing me to do the same? Am I missing something, or this support is not in place and planned for a future release?

I know that OpenAPI 3.1 supports request body with GET requests - I wouldn't fully agree with this claim.

Here is what OpenAPI 3.0.3 has to say about it:

image

Here is what OpenAPI 3.1.0 has to say about it:

image


Now if we take GET method and read what RFC7231 has to say about it:

image

OpenAPI 3.1.0 considers RFC7231s no defined semantics to be vague, but HTTP clients in JavaScript (Fetch API, XHR, Node.js) don't consider it vague and just forbids to send any payloads along with the GET requests. This is not specific to SwaggerUI, this is specific to JavaScript HTTP APIs. As far as I can tell it is not possible to send GET request with payload in JavaScript.

SwaggerUI will pass your GET request as it is to the underlying HTTP client. Inside browser, the HTTP clients happens to be Fetch API. Fetch API doesn't allow to do GET requests with payloads and triggers the type error you're seeing: 'TypeError: Failed to execute 'fetch' on 'Window': Request with GET/HEAD method cannot have body'.


Best way to avoid this issue to comply with the OpenAPI 3.1.0 and RFC7231 and not use payloads for HTTP methods, which do not have semantics explicitly defined.

@char0n char0n closed this as completed May 18, 2023
soksanichenko added a commit to AlmaLinux/albs-web-server that referenced this issue Oct 26, 2023
…use it puts sRPM to a wrong repo

- Select only right rpm repositories by a platform while processing a build task artifacts
- Update built_srpm_url only for the build tasks of one platform
- HTTP-method for route `get_task` is changed from GET to POST, because it sends a request's body (because swagger-api/swagger-ui#8682 & RFC7231)
- Some typing is changed for better autocompleting and linting
- Select and put noarch packages only among the build tasks of one platform
- Create raw_refs per each existing platform, not only first platform from the list
github-actions bot pushed a commit to AlmaLinux/albs-web-server that referenced this issue Oct 26, 2023
…use it puts sRPM to a wrong repo

- Select only right rpm repositories by a platform while processing a build task artifacts
- Update built_srpm_url only for the build tasks of one platform
- HTTP-method for route `get_task` is changed from GET to POST, because it sends a request's body (because swagger-api/swagger-ui#8682 & RFC7231)
- Some typing is changed for better autocompleting and linting
- Select and put noarch packages only among the build tasks of one platform
- Create raw_refs per each existing platform, not only first platform from the list
soksanichenko added a commit to AlmaLinux/albs-web-server that referenced this issue Oct 26, 2023
…use it puts sRPM to a wrong repo

- Select only right rpm repositories by a platform while processing a build task artifacts
- Update built_srpm_url only for the build tasks of one platform
- HTTP-method for route `get_task` is changed from GET to POST, because it sends a request's body (because swagger-api/swagger-ui#8682 & RFC7231)
- Some typing is changed for better autocompleting and linting
- Select and put noarch packages only among the build tasks of one platform
- Create raw_refs per each existing platform, not only first platform from the list
soksanichenko added a commit to AlmaLinux/albs-node that referenced this issue Oct 26, 2023
…use it puts sRPM to a wrong repo

- HTTP-method for route `get_task` is changed from GET to POST, because it sends a request's body (because swagger-api/swagger-ui#8682 & RFC7231)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants