zaproxy/zaproxy · error · ApiException

BAD_FORMAT

BAD_FORMAT

Error message

The format OTHER should not be used with views and actions.

What it means

validateFormatForViewAction enforces that views and actions only support JSON, JSONP, XML, and HTML formats. If the request's format resolves to OTHER (or any other non-view format), it throws ApiException(Type.BAD_FORMAT) with message 'The format OTHER should not be used with views and actions.' Format OTHER is reserved for handlers that don't map to the standard renderers.

Source

Thrown at zap/src/main/java/org/zaproxy/zap/extension/api/API.java:732

        }
    }

    /**
     * Validates that the given format is supported for views and actions.
     *
     * @param format the format to validate.
     * @throws ApiException if the format is not valid.
     * @see #convertViewActionApiResponse(Format, String, ApiResponse)
     */
    private static void validateFormatForViewAction(Format format) throws ApiException {
        switch (format) {
            case JSON:
            case JSONP:
            case XML:
            case HTML:
                return;
            default:
                throw new ApiException(
                        ApiException.Type.BAD_FORMAT,
                        "The format OTHER should not be used with views and actions.");
        }
    }

    /**
     * Returns a URI for the specified parameters.
     *
     * <p>An {@link #getOneTimeNonce(String) one time nonce query parameter} is added to the
     * resulting URL, if required (that is, not a view). In this case the URL is ended with an
     * ampersand (for example, {@code https://zap/format/prefix/action/name/?apinonce=xyz&}),
     * otherwise it has a trailing slash (for example, {@code http://zap/format/prefix/view/name/}).
     *
     * @param format the format of the API response
     * @param prefix the prefix of the API implementor
     * @param type the request type
     * @param name the name of the endpoint
     * @param proxy if true then the URI returned will only work if proxying via ZAP, i.e. it will

View on GitHub (pinned to 9d1970a436)

Solutions

Remove the format parameter entirely (views/actions default to the endpoint's format implied by the path prefix) or set it to json, xml, html, or jsonp.
Use /OTHER/... endpoints only for handlers explicitly registered for the OTHER format, not for views/actions.
Fix URL templating so a literal/placeholder format value isn't sent.
Validate format at the client side against the allowed set {JSON, JSONP, XML, HTML} before calling.

Example fix

// before
curl 'http://localhost:8080/JSON/core/view/version/?format=OTHER'
// after
curl 'http://localhost:8080/JSON/core/view/version/?format=json'

Defensive patterns

Strategy: validation

Validate before calling

const ALLOWED = new Set(['JSON','JSONP','XML','HTML']);
if ('format' in params && !ALLOWED.has(params.format.toUpperCase())) {
  throw new Error(`format must be one of ${[...ALLOWED]} for views/actions`);
}

Try / catch

try {
  return await zap.view(name, { format });
} catch (e) {
  if (e.code === 'BAD_FORMAT') {
    return zap.view(name, { format: 'JSON' }); // drop/normalize the format
  }
  throw e;
}

Prevention

Omit the format param unless you specifically need a non-default renderer.
Never pass format=OTHER to /JSON/,/XML/,/HTML/ view or action paths.
Whitelist formats in any URL builder that interpolates format.
Test clients after template changes that affect query params.

When it happens

Trigger: Calling any /JSON/... or /XML/... view or action endpoint with format=OTHER (or an invalid format string that defaults to OTHER), e.g. GET /JSON/core/view/version/?format=OTHER.

Common situations: Clients copying a format parameter from a different endpoint type; scripts with a corrupted/typo'd format value that the parser coerces to OTHER; templated request generators leaving a placeholder format value.

Related errors

AI-assisted analysis of zaproxy/zaproxy@9d1970a436 (2026-09-05). Data as JSON: /api/errors/a82dfbd7814967d7. Report an issue: GitHub.