[BUG][dart-dio-next] Generator uses url encoded contentType even if the server content type requires application/json

Bug Report Checklist

• Have you provided a full/minimal spec to reproduce the issue?
• Have you validated the input using an OpenAPI validator (example)?
• Have you tested with the latest master to confirm the issue still exists?
• Have you searched for related issues/PRs?
• What’s the actual output vs expected output?
• [Optional] Sponsorship to speed up the bug fix or feature request (example)

Description

I’m using Asp.Net Core Swashbuckle to generate openapi scheme for my backend. The backend supports multiple content-type variants of application/json. But generated code uses url encoded content type instead of application/json.

Here’s generated code output which picks first match which is “application/json-patch+json”.

contentType: [
  'application/json-patch+json',
  'application/json',
  'text/json',
  'application/_*+json',
].first

But then Did checks if content-type is application/json then uses json encoding but if it isn’t, it uses url encoding and my server returns HTTP 415 Unsupported Media Type status.

openapi-generator version

5.1.0

OpenAPI declaration file content or url

The OpenAPI declaration that caused this issue was used for private api. So I couldn’t share it here.

Generation Details

Steps to reproduce

Related issues/PRs

Suggest a fix

1. Overriding content-type header using command line options provided to generator CLI
2. Updating contentType matching part to choose most suitable match rather than first one

[kuhnroyal]

No, I don’t think so. Basically for dio and Dart, we only care about application/json, application/x-www-form-urlencoded and multipart/form-data. Everything else we need to directly filter out and if none of these match we should probably add a warning and default to json.

[themisir]

Thanks for the report. You can try changing the order of the content-types in the spec around, not sure if that works.

I’ve already fixed the issue by manually modifying generated dart code (since scheme is generated on runtime on our backend, modifying dart generated code is way easier for me).

But I think this needs to be fixed. Actually I can work on this issue but I might need a bit of direction for contributing (for example which file(s) implements dart-dio-next generation).