Error 404 and 405 of cross origin when using Microservice

What product/components do you use and which version/fix level are you on?

I use Microservice of Cumulocity IoT Platform, the tenant is bulut-dik-2021

Is your question related to the free trial, or to a production (customer) instance?

free trial

What are you trying to achieve? Please describe it in detail.

I upload a web application to microservice, this web application was built using the flask framework. The entire web application has several html files linked to each other and uses css file for the design of the pages.

Do you get any error messages? Please provide a full error message screenshot and log file.

I cannot click on any of the links in the first web page to get to other pages and when I do, I get a 404 error. Also, the css file I used to design the page could not be linked, the error type was 405. I think the problem is about cross origin, because there was no problem running the image file of the web application on docker, and it was the same image file that I uploaded to microservice. (ps: I have already used the tutorial of “helloworld” and there is no problem)

Have you installed all the latest fixes for the products and systems you are using?


your application is not aware that it is hosted on another path (behind a reverse proxy).
Instead of requesting e.g. the style sheets from it should actually request them from

The same is also the case for the login, your links should be relative to the current path, otherwise this won’t work.

In case your applications UI is static and only requests data from the backend, you may also want to consider uploading the UI and backend as two separate apps (the UI as a hosted web application).

the style sheets has been requested successfully with the path of /service/droneservice/static/styles.css. But this method didn’t work for the html files. E.g., the login page with the path of /service/droneservice/login can not be found. (404). I have just changed the route. Is it wrong?


the route within your service should probably still be listening for requests to /login instead of /service/droneservice12/login.
Maybe you can add a middleware for debugging purposes that will log all incoming requests? Then you would see that the /login route is requested and not /service/droneservice12/login through the reverse proxy.


This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.