OpenAPITools / OpenAPITools/openapi-generator

[BUG] Content-Type headers for */* contents always default to application/json in client generation

Open
#7,059 2 comments 3 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Issue: Bug
Dominant language
Java
Stars
26.8k
Forks
7.7k
PR merge metrics
PR metrics pending

Description

Bug Report Checklist
  • Have you provided a full/minimal spec to reproduce the issue?
  • Have you validated the input using an OpenAPI validator (example)?
  • What's the version of OpenAPI Generator used?
  • Have you search for related issues/PRs?
  • What's the actual output vs expected output?
  • [Optional] Bounty to sponsor the fix (example)
Description

If an open api specification wants to support an arbitrary content type or arbitrary file uploading, they might use */* as a key in their contents list for a given endpoint. However, when generating a client for this specification using RestTemplate, the Content-Type header is always sent as application/json.

I would expect the code to be able to support setting custom headers, or at the very minimum, default to usingapplication/octet-stream. Using application/json is problematic, because the API could be expecting something completely different- for example, a content-type of image/jpeg.

Currently, the code essentially has this application/json header hardcoded into it. This means its not configurable at all. I currently don't see any way to change this behavior in configuration

Note: there is an unrelated unresolved bug regarding the File type mapping, see #2486. This is why there is a FileMapping in the example config. This further hinders successful use of the module.

openapi-generator version

Maven plugin v 4.3.1, for Java

OpenAPI declaration file content or url

https://gist.github.com/lgnashold/c61a116272bcca9945cfc2c6dcf53546

Command line used for generation

This was generated with the Maven plugin. Here is the relevant POM:
https://gist.github.com/lgnashold/8fe9ed3309eadc7a1e1cb1436e2b966a
I could try to translate this into a CLI command, but I am not as familiar with the CLI so I will not do this unless necessary.

Steps to reproduce
  1. Generate the code with the POM provided and the test config.
  2. Attempt to use the testOp method within the TestApi Api class. You can use Java code similar to the following
PredictionsApi api = new PredictionsApi();
File f = new File("<filepath>");
Resource resource = new FileSystemResource(f);
api.testOp(resource);
  1. Notice that the generated POST request has a Content-Type of application/json, using either a debugger (try setting a breakpoint in selectHeaderContentType) or by setting up a local server.
Related issues/PRs

#476 looks like it is where the problematic code originated from.
#6779 Is a similar problem, except for the accept header instead of the content-type header. It has been open since June with no comments, however.

Suggest a fix

It seems to me that if the MIME type is arbitrary, each path endpoint method in the generated Api object should be able to pass in a parameter with a String representing the Content-Type. Barring that, the next best thing would to be able to configure the Api or the ApiClient to be able to set the default headers.

These fixes would involve changing the generated method selectHeaderContentType and calls to it.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the generated TestApi.testOp call and the selectHeaderContentType entry point referenced in the report, then trace its calls in the generated Api class and ApiClient. Reproduce with the linked OpenAPI specification and Maven configuration, checking the request sent to a local server. Done means / content no longer unconditionally produces application/json and the resulting behavior is covered by tests.

Written by the indexing model from the issue text.

Assessment

Tech stack
java, spring
Domain
api, backend
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.