Why does Membrane return 500 Error rewriting URI?

The WSDL rewriter could not rewrite the endpoint addresses and schema locations in a WSDL or XSD response. Usually the response is labeled as XML but is not well-formed, contains a DOCTYPE, or the WSDL or a referenced schema could not be found.

Which Membrane plugins rewrite WSDL documents?

The wsdlRewriter plugin, and internally the wsdlPublisher plugin and the soapProxy. All of them report failures under this URL.

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. Membrane then leaves out detailed information, such as the exception message and the link to the documentation, from error responses.

500 Internal Server Error: Error Rewriting URI

Membrane API Gateway returns 500 Internal Server Error with the detail Error rewriting URI when the WSDL rewriter cannot rewrite the endpoint addresses and schema locations in a WSDL or XSD response.

The Error Response

The response contains the status 500 Internal Server Error, the detail Error rewriting URI, the problem type https://membrane-api.io/problems/internal and a link to this page. The URI field shows the requested path. The type internal means that the gateway could not complete the processing of the message. In production mode, the title is replaced by Internal Server Error and the details are left out.

What the WSDL Rewriter Does

When a client downloads a WSDL through the gateway, the addresses in it must point to the gateway instead of the backend. The rewriter changes the endpoint location and the schemaLocation values accordingly. It runs in the response flow for GET requests whose response is labeled as XML. It runs as the wsdlRewriter plugin, and internally in wsdlPublisher and soapProxy.

Common Causes

The Response Is Not Well-Formed XML

The response is labeled as XML, for example with text/xml, but its body is not well-formed XML. A typical case is an HTML error page from the backend that carries an XML content type.

The Document Contains a DOCTYPE

The WSDL or XSD contains a DOCTYPE. Membrane's hardened XML parser rejects DTDs.

The WSDL or a Schema File Is Missing

Inside wsdlPublisher or soapProxy: the configured WSDL, or a schema it references, cannot be resolved. The error document for the missing file is then passed to the rewriter, which fails on it. The underlying problem is the missing file, see Could not resolve file.

An Invalid URL in the WSDL or in path

With wsdlRewriter and its path setting: rewriting a location or schemaLocation value fails because the value or path is not a valid URL.

The Body Cannot Be Read

The response body cannot be read or decoded, for example because the Content-Encoding is wrong.

An Unexpected Exception in the Plugin

The same link also appears when the wsdlRewriter plugin throws an exception that it does not turn into an error response itself. Membrane then aborts the exchange with 500 Internal Server Error, and the detail reads Aborting! Exception caused in wsdl-rewriting during … flow. with the request URI and the flow. Membrane logs every occurrence with the full stack trace. Unless the exception points to your configuration or to the message content, this usually indicates a bug in Membrane.

How to Fix It

Backend: return a well-formed WSDL or XSD without a DOCTYPE, and use an XML content type only for XML bodies.
wsdlPublisher and soapProxy: check that the wsdl and all referenced schemaLocation paths exist. Relative paths are resolved against the directory of the configuration file.
wsdlRewriter: check that path and the addresses in the WSDL are valid URLs.
Check the gateway log, where the exception is logged at error level. If the causes above do not explain it, report the problem with the stack trace on GitHub Issues.

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 the details and the link to this page are left out. If the response contains a log key, search the gateway log for it to find the full error message.

If the plugin is nested inside a request, response or abort element and fails with an unexpected exception there, 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.