415 Unsupported Media Type: "Content-Type 'application/json' is not supported

Hello All,

I am trying to access OOTB Tasklist REST API in my self-managed instance which is running on AWS EKS cluster. When I am trying to execute the Search tasks of Tasklist REST from both the postman or java code, I am getting error "415 Unsupported Media Type: “Content-Type ‘application/json’ is not supported”

I have passed Content-Type header as application/json in case of postman and in case of Java code I passed both Content-Type & Accept header as application/json.

But the same Java code is working with Camunda SaaS Tasklist API.

Surprisingly when I am trying to open swagger documentation in browser I am getting “Content-Type is missing from the request”.

I am though able to generate Bearer token using Authentication API in self-managed after changing the Content-Type as “application/x-www-form-urlencoded”

Kindly point me what I am missing here.

@nathan.loding - Any input on this issue that I am facing?

Hi @arijit.chanda,

I noticed the same difference between SaaS and SM: the content type can be application/json when generating the Bearer token in SaaS, but needs to be application/x-www-form-urlencoded in SM.

But, after generating a valid Bearer token, in my experience, it should be possible to send the exact same request to the Task List rest api (using content type application/json) regardless of whether it’s SaaS or SM.

Here’s a simple java project I put together a few weeks ago that might help you troubleshoot:

You might try to run this SM unit test to troubleshoot your environment:

This unit test has worked against many PoC SM environments that I’ve used over the past weeks. So, if it fails for you, then I’m suspicious that perhaps your AWS load balancer or ingress configuration is possibly causing some strangeness related to the content type header?

1 Like

Thanks @Dave_Paroulek for your quick response. Finally I was able to access self-managed Tasklist REST API without any issue.

Mistake from my end was, I was providing wrong baseurl of Tasklist REST API. I was trying with https://{{HostName}}/v1/tasks/search but after seen your example I got to know that in case of self-managed instance, the baseurl would be {{HostName}}/tasklist i.e. complete url would be like https://{{HostName}}/tasklist/v1/tasks/search.

As per Camunda API documentation, only local instance example was given along with SaaS so I was using like that only.

Thanks once again for helping to resolve my mistake.

Lastly, any idea why swagger documentation is not opening for my self-managed instance? I am getting below error

Hey @arijit.chanda, check your ingress rules. I’m guessing that you have a path configured that looks like this?

$> kubectl describe ingress camunda-camunda-platform -n camunda
  Host                    Path       Backends
  ----                   ----            --------
                         /tasklist     camunda-tasklist:80 (10.xxx.x.xx:8080)

If so, I think if you include the context path /tasklist it should come up?

1 Like

Thanks @Dave_Paroulek for the input. I checked the ingress configuration and now able to open Tasklist API related swagger using https://{your-host}/tasklist/swagger-ui/index.html. But I am not able to open other API (Operate, Optimize, Web-Modeler) related swagger using same approach.

PFB my ingress path configurations -

Errors that I getting -



Optimize: It’s redirecting to login page and after login Optimize is opening.

Hi @arijit.chanda - the issue with Operate is strange … why is it trying to load a definition for https://petstore.swagger.io/v2/swagger.json? Does Operate work if you open it through https://<AWS DOMAIN>/operate/?

For Web Modeler, the path is different - instead of /swagger-ui/index.html just navigate to swagger-ui.html (docs reference).

Hi @nathan.loding @Dave_Paroulek - All components (like web modeler, tasklist, java zeebe client) are working absolutely fine in my self-managed AWS instance. Though I couldn’t able to validate OOTB connectors yet, will do that.

Surprisingly once I logged-in to any portal like Tasklist/Operate and then opened the Operate swagger documentation in the same browser in another tab using https://< AWS DOMAIN>/operate/swagger-ui.html, it opened.

But Web-modeler and Optimize swagger document isn’t opening. I tried with below URL:
https://< AWS DOMAIN>/modeler/swagger-ui.html
https://< AWS DOMAIN>/optimize/swagger-ui.html

Is there any specific configuration required to enable swagger documentation for web-modeler & optimize? If I trying to open Optimize swagger documentation, Optimize portal is opening.

Also I couldn’t figure out why opening of operate swagger documentation requires authentication.

Hi @arijit.chanda - Swagger requires authentication in our current builds. (I think we could make that more clear in our documentation, and I’ll bring this feedback to our docs team!)

I missed your last sentence about Optimize. Optimize does not currently provide a Swagger UI/OpenAPI definition. It is on the roadmap though!

I think for Web Modeler there is a webmodeler-restapi image that also needs to be deployed, which I don’t see in your provided screenshots. Are you using Docker or Helm? Can you share your docker-compose.yaml or values.yaml file (make sure to remove any private information and secrets before sharing!)?

Thanks @nathan.loding for spending your time to resolve the issue I am facing, really appreciable.

I used Helm chart to install the camunda in AWS EKS.

PFB the pods, services and ingress of camunda-platform. Web-modeler rest-api pod and service is there and it’s running but there is no separate path configured for web-modeler rest-api.

PFA the helm value file for your reference.
camunda-values-v8.3.yaml (7.6 KB)

Looking for your input.

@arijit.chanda - this is something I haven’t had to figure out before! I’ve asked some internal teams for their suggestions. In the meantime, trying to think about it logically:

  • can you access the Web Modeler application, or does the app fail to load?
  • can you access the Web Modeler API? (https://<AWSDOMAIN>/modeler/api/v1/info)

Hi @nathan.loding -

  • can you access the Web Modeler application, or does the app fail to load? - It’s opening absolutely fine and I am able to model, deploy, run BPMN from web-modeler application.
  • can you access the Web Modeler API? (https://<AWSDOMAIN>/modeler/api/v1/info) - It’s working in postman. I received below response as well which is proper.

Whereas when I am trying to execute any post, put/ delete related web-modeler REST api, I am getting “Bad Request - CSRF verification failed!”. Due to this error, I am not able to use any modeler related API.

Can you please help me how to resolve this error?

@arijit.chanda - I come with good and not as good news. Both of these issues you are experiencing are, in fact, bugs. The good news: the bugs are identified, and the team is working on the fixes (here is a public GitHub issue you can follow). Swagger not loading and the CSRF issues. The not as good news: I don’t currently have a workaround or a date that they expect to release a fix. If I hear an answer for either of those, I’ll let you know!

Thanks @nathan.loding for the update. If you hear anything kindly update me.

As the web-modeler REST API isn’t working at this moment, is there any other way (except modeler manual export feature) to export artifacts like BPMN, DMNs so that I can integrate with CI/CD pipeline to deploy those artifacts in my cluster?

Unfortunately I don’t think so. Both of the issues (Swagger + CSRF) share the same root cause: Modeler isn’t properly handling the ingress path, so the good news is that a fix is relatively simple and the team expects to have a fix in a patch release in the beginning of January.

Thanks @nathan.loding for the update. I will wait for the patch to release. Kindly update me once the patch released.

@nathan.loding - Do you have any update on this? Recently 8.4 version released. Should I upgrade my cluster with 8.4 version so that the issue will be resolved?

Hi @arijit.chanda - apologies for a small delay, I was off on holiday! The releases last week should resolve this for you. Web Modeler was patched in the following versions: 8.2.10 , 8.3.3 and 8.4.1

Thanks @nathan.loding for the update. I will keep you posted once I upgraded and verified my self-managed instance.

1 Like

Thanks @nathan.loding , Now it’s working with v8.4.1. Thanks a lot for your effort to resolve the issue.

1 Like