Why does Membrane return 500 Error inspecting body!?

The xmlProtection plugin failed unexpectedly while inspecting the request body. Usually the Content-Type header of the request cannot be parsed or names an illegal or unsupported charset.

Is this an XML policy violation?

No. Policy violations, malformed XML and unprocessable multipart bodies get 400, disallowed content types 415. This 500 means the inspection itself failed.

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 Inspecting Body

Membrane API Gateway returns 500 Internal Server Error with the detail Error inspecting body! when the xmlProtection plugin fails unexpectedly while it inspects a request body. In most cases the Content-Type header of the request triggers it.

The Error Response

The response contains the status 500 Internal Server Error, the detail Error inspecting body!, the problem type https://membrane-api.io/problems/internal and a link to this page. In development mode, the reason field contains the exception message. 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 XML Protection Plugin Does

The xmlProtection plugin protects backends against XML attacks by limiting the size, depth and structure of XML requests. Violations of these limits are not reported here: they, malformed XML and unprocessable multipart bodies get a 400, disallowed content types a 415, and unreadable bodies a separate body read error.

Common Causes

The Content-Type Header Cannot Be Parsed

The Content-Type header is malformed, so Membrane cannot decide whether the body is multipart.

An Illegal or Unsupported Charset

The charset parameter of the Content-Type header, or of the header of a multipart part, names an illegal or unsupported charset, for example text/xml; charset=foo.

An Encoding Java Cannot Load

The XML declaration may name an encoding that the XML parser accepts but Java cannot load as a charset. This cause has not been reproduced; in many cases the parser rejects such an encoding first.

An Unexpected Exception in the Plugin

The same link also appears when the xmlProtection 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 xml-protection 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

Client side: send a well-formed Content-Type header with a standard charset name such as UTF-8, or omit the charset.
Gateway operator: the message is logged at info level as Could not inspect the XML body: …, the stack trace at debug 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.