dotnetcore/CAP · error · Exception

Error when parsing incoming request, exception

Error message

Error when parsing incoming request, exception: {ex.Message}

What it means

The Dashboard's default IRequestMapper (Map method) wraps any failure while converting the incoming HttpRequest into an HttpRequestMessage in a generic Exception: "Error when parsing incoming request, exception: {ex.Message}". The inner message (e.g. a null-scheme ArgumentNullException from BuildAbsolute) is the real cause; only ex.Message is preserved, so the original stack trace and type are lost.

Solutions

  1. Inspect the inner '{ex.Message}' text to identify the real cause (e.g. 'Parameter scheme') and fix the incoming request configuration.
  2. Ensure ForwardedHeaders middleware is configured so HttpContext.Request.Scheme is populated behind a proxy.
  3. Change the wrapper to throw with InnerException preserved: throw new Exception(msg, ex) for diagnosability.
  4. Log the full exception server-side instead of only ex.Message.

Example fix

// before
throw new Exception($"Error when parsing incoming request, exception: {ex.Message}");
// after
throw new Exception("Error when parsing incoming request", ex); // preserves type + stack
Defensive patterns

Strategy: try-catch

Try / catch

try
{
    var req = await mapper.MapAsync(request);
}
catch (Exception ex) when (ex.Message.StartsWith("Error when parsing incoming request"))
{
    logger.LogError(ex, "Dashboard request mapping failed: {Message}", ex.Message);
    return StatusCode(400);
}

Prevention

When it happens

Trigger: Any exception inside Map's try block when building the proxied request: MapHeaders, BuildAbsolute/GetEncodedUrl failures (e.g. null scheme), malformed request Uri construction against the dashboard node.

Common situations: Accessing the Dashboard through a reverse proxy that strips the scheme, misconfigured forwarded headers, or unusual request URLs that make UriBuilder/GetEncodedUrl throw.

Understand the failure class

Background: 'Something went wrong' / 'Request failed (500)' / 'HTTP error! status: 404' — what failed HTTP requests actually mean and how to find the real cause — this error's family across 28 libraries.

Related errors


AI-assisted analysis of dotnetcore/CAP@e52b8508e5 (2026-09-14). Data as JSON: /api/errors/20e04e67e50002bc. Report an issue: GitHub.

Appendix: source

Thrown at src/DotNetCore.CAP.Dashboard/GatewayProxy/IRequestMapper.Default.cs:38

    public async Task<HttpRequestMessage> Map(HttpRequest request)
    {
        try
        {
            var requestMessage = new HttpRequestMessage
            {
                Content = await MapContent(request),
                Method = MapMethod(request),
                RequestUri = MapUri(request)
            };

            MapHeaders(request, requestMessage);

            return requestMessage;
        }
        catch (Exception ex)
        {
            throw new Exception($"Error when parsing incoming request, exception: {ex.Message}");
        }
    }

    private string BuildAbsolute(
        string scheme,
        HostString host,
        PathString pathBase = new(),
        PathString path = new(),
        QueryString query = new(),
        FragmentString fragment = new())
    {
        if (scheme == null) throw new ArgumentNullException(nameof(scheme));

        var combinedPath = pathBase.HasValue || path.HasValue ? (pathBase + path).ToString() : "/";

        var encodedHost = host.ToString();
        var encodedQuery = query.ToString();
        var encodedFragment = fragment.ToString();

View on GitHub (pinned to e52b8508e5)