Why does Membrane return 500 Could not parse target URL?

The reverseProxying plugin rewrites a WebDAV Destination header and needs the absolute URL of the backend. The API has no HTTP target, or the target uses a scheme such as internal://, so the destination cannot be parsed.

How do I fix Could not parse target URL in Membrane?

Use reverseProxying only in APIs that forward to an HTTP or HTTPS backend with target url or target host and port. Remove it from APIs without a target or with internal routing.

How do I hide the details in Membrane error responses?

Enable production mode by adding a configuration document with production: true to your apis.yaml. The response then only contains a log key that you can look up in the gateway log.

500 Internal Server Error: Could Not Parse Target URL

Membrane API Gateway returns 500 Internal Server Error with the detail Could not parse target URL when the reverseProxying plugin cannot parse the destination of the exchange as an absolute URL while it rewrites a Destination header. This is a gateway configuration issue.

The Error Response

The response contains the status 500 Internal Server Error, the title Internal server error., the detail Could not parse target URL, the problem type https://membrane-api.io/problems/internal and a link to this page. In development mode, the destination that could not be parsed is included as URL, together with the exception message. The type internal means that the gateway could not complete the processing of the exchange. In production mode, the title is replaced by Internal Server Error and the details are left out.

What the Reverse Proxying Plugin Does

The reverseProxying plugin rewrites URLs so that clients keep talking to the gateway instead of the backend. For a request with a WebDAV Destination header that points to the gateway's own scheme, host and port, it replaces them with those of the backend. To do this, it parses the destination the gateway forwards to as an absolute URL. If that fails, it answers with this error in the request flow.

Common Causes

The API Has No Target

An API that answers with plugins such as return or static has no backend. The destination is then still the bare request path, for example /files/a.txt, which is not an absolute URL.

The Target Uses an Unknown Scheme

A target URL with a scheme other than HTTP or HTTPS, for example internal://… for internal routing, cannot be parsed.

An Unexpected Exception in the Plugin

Any other exception that the reverseProxying plugin does not turn into an error response itself is reported under the same URL by Membrane's generic error handler. The detail then reads Aborting! Exception caused in … flow. and names the plugin, the request URI and the flow. Unless the exception points to your configuration or to the message, this usually indicates a bug in Membrane.

How to Fix It

Use reverseProxying only in APIs that forward to an HTTP or HTTPS backend through target with url or host and port.
Remove reverseProxying from APIs without an HTTP target and from APIs that route internally.
Look for Could not parse target URL: … in the log, or at the URL field of the response in development mode, to see the destination.

api:
  port: 2000
  flow:
    - reverseProxying: {}
  target:
    url: http://localhost:8080

api:
  port: 2000
  flow:
    - reverseProxying: {}
  target:
    url: http://localhost:8080

Hide Details in Production

By default, Membrane runs in development mode and adds details to error responses that help you find the problem. These details may reveal information about your setup. In production, turn them off:

configuration:
  production: true

configuration:
  production: true

Add the configuration document to your apis.yaml and separate it from the APIs with ---. The title then reads Internal Server Error, and instead of the details the response only contains a log key. Search the gateway log for this key to find the exception.

If the plugin is nested inside a request, response or abort element and throws an unexpected exception, the exception message, the stack trace and the link to this page are currently sent even in production mode. Fix the failing plugin rather than relying on production mode to hide them.