Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • O openapi-generator
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 3,476
    • Issues 3,476
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 402
    • Merge requests 402
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • OpenAPI Tools
  • openapi-generator
  • Issues
  • #3276
Closed
Open
Issue created Jul 03, 2019 by Administrator@rootContributor5 of 6 checklist items completed5/6 checklist items

[BUG][JAVA][Client] Regression: Unconditionally sends empty object request body

Created by: kevinoid

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

The java okhttp-gson client (and likely other Java clients) always send an empty object in the request body for DELETE (and likely POST and PUT) operations which do not define requestBody. Since DELETE request payload has no defined semantics this is likely to cause compatibility issues (and causes 4XX responses from the API I am working with).

openapi-generator version

The issue first appeared in 0fb1ffa8 (#98) and still occurs on master (0cb92125).

OpenAPI declaration file content or url
openapi: '3.0.2'
info:
  title: delete example
  version: '1.0.0'
servers:
- url: http://example.com/api
components:
  schemas:
    Error:
      type: object
      properties:
        message:
          type: string
paths:
  /:
    delete:
      responses:
        '204':
          description: Deleted
        default:
          description: Error
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Error'

(Note: At least one schema must be defined for the generated code to compile, so I added Error for this purpose.)

Command line used for generation

openapi-generator-cli.jar generate -i openapi.yaml -g java -o openapi-generator-test-client

Steps to reproduce
  1. Generate the code using the YAML spec and command from above, replacing example.com/api with a test server.
  2. Create src/main/java/TestApp.java with content
import org.openapitools.client.*;
import org.openapitools.client.api.*;

public class TestApp {
    public static void main(String[] args) throws ApiException {
        ApiClient apiClient = new ApiClient();
        DefaultApi defaultApi = new DefaultApi(apiClient);
        defaultApi.rootDelete();
    }
}
  1. Run gradle -DmainClass=TestApp execute and observe traffic on the test server.

The client generated from code before 0fb1ffa8 will send:

DELETE /api/ HTTP/1.1
Accept: application/json
Content-Type: application/json
User-Agent: OpenAPI-Generator/1.0.0/java
Host: example.com
Connection: Keep-Alive
Accept-Encoding: gzip

The client generated with 0fb1ffa8 or later will send:

DELETE /api/ HTTP/1.1
Accept: application/json
User-Agent: OpenAPI-Generator/1.0.0/java
Content-Type: application/json; charset=utf-8
Content-Length: 2
Host: example.com
Connection: Keep-Alive
Accept-Encoding: gzip

{}
Suggest a fix

This was fixed for resttemplate by #605 but not for jersey2, okhttp-gson, or resteasy. Reverting 0fb1ffa8 for the other clients would fix this, but presumably reintroduce #98 (although I'm not sure why Jackson would be called to serialize null, presumably we could just stop doing that).

Thoughts from the participants on #98 and #605? @bmordue, @jmini, @rubms

Assignee
Assign to
Time tracking