Matched requests that contain invalid header values (eg with emoji) return a 502 to the client

[Laura7089]

The expected behaviour of this should be to return a 4XX error to the client.

Reproducing

Reproduced against the Basic sample on tag 24.1.0 with:

curl -X GET -v 'http://localhost:5555/ocelot/posts/askdj' \
  --header 'Accept: */*' \
  --header 'skull: 💀'

Prints:

Note: Unnecessary use of -X or --request, GET is already inferred.
* Host localhost:5555 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying [::1]:5555...
* Established connection to localhost (::1 port 5555) from ::1 port 57284
* using HTTP/1.x
> GET /ocelot/posts/askdj HTTP/1.1
> Host: localhost:5555
> User-Agent: curl/8.19.0
> Accept: */*
> skull: 💀
>
* Request completely sent off
< HTTP/1.1 502 Bad Gateway
< Content-Length: 0
< Date: Mon, 30 Mar 2026 14:01:37 GMT
< Server: Kestrel
<
* Connection #0 to host localhost:5555 left intact

Logs

The logs shed some light:

info: Microsoft.AspNetCore.Hosting.Diagnostics[1]
      Request starting HTTP/1.1 GET http://localhost:5555/ocelot/posts/askdj - - -
dbug: Ocelot.Errors.Middleware.ExceptionHandlerMiddleware[0]
      RequestId: 0HNKECIQOAUK4:00000001, PreviousRequestId: -
      Ocelot pipeline started
dbug: Ocelot.DownstreamRouteFinder.Middleware.DownstreamRouteFinderMiddleware[0]
      RequestId: 0HNKECIQOAUK4:00000001, PreviousRequestId: -
      Upstream URL path: /ocelot/posts/askdj
dbug: Ocelot.DownstreamRouteFinder.Middleware.DownstreamRouteFinderMiddleware[0]
      RequestId: 0HNKECIQOAUK4:00000001, PreviousRequestId: -
      Downstream templates: /todos/{id}
info: Ocelot.RateLimiting.RateLimitingMiddleware[0]
      RequestId: 0HNKECIQOAUK4:00000001, PreviousRequestId: -
      Rate limiting is disabled for route '/ocelot/posts/{id}' via the EnableRateLimiting option.
info: Ocelot.Authentication.AuthenticationMiddleware[0]
      RequestId: 0HNKECIQOAUK4:00000001, PreviousRequestId: -
      No authentication is required for the path '/ocelot/posts/askdj' in the route /ocelot/posts/{id}.
dbug: Ocelot.Authorization.AuthorizationMiddleware[0]
      RequestId: 0HNKECIQOAUK4:00000001, PreviousRequestId: -
      No authorization needed for the route: /ocelot/posts/{id}
dbug: Ocelot.DownstreamUrlCreator.DownstreamUrlCreatorMiddleware[0]
      RequestId: 0HNKECIQOAUK4:00000001, PreviousRequestId: -
      Downstream URL: https://jsonplaceholder.typicode.com/todos/askdj
info: Ocelot.Requester.Middleware.HttpRequesterMiddleware[0]
      RequestId: 0HNKECIQOAUK4:00000001, PreviousRequestId: -
      102 unknown status code of request URI: 
dbug: Ocelot.Requester.Middleware.HttpRequesterMiddleware[0]
      RequestId: 0HNKECIQOAUK4:00000001, PreviousRequestId: -
      IHttpRequester returned an error, setting pipeline error
warn: Ocelot.Responder.Middleware.ResponderMiddleware[0]
      RequestId: 0HNKECIQOAUK4:00000001, PreviousRequestId: -
      ResponderMiddleware found 1 error ->
      ConnectionToDownstreamServiceError: Error connecting to downstream service, exception: System.Net.Http.HttpRequestException: Request headers must contain only ASCII characters.
         at System.Net.Http.HttpConnection.<WriteString>g__ThrowForInvalidCharEncoding|55_0()
         at System.Net.Http.HttpConnection.WriteString(String s, Encoding encoding)
         at System.Net.Http.HttpConnection.WriteHeaderCollection(HttpHeaders headers, String cookiesFromContainer)
         at System.Net.Http.HttpConnection.WriteHeaders(HttpRequestMessage request)
         at System.Net.Http.HttpConnection.SendAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
         at System.Net.Http.HttpConnection.SendAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
         at System.Net.Http.HttpConnectionPool.SendWithVersionDetectionAndRetryAsync(HttpRequestMessage request, Boolean async, Boolean doRequestAuth, CancellationToken cancellationToken)
         at System.Net.Http.DiagnosticsHandler.SendAsyncCore(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
         at Ocelot.Requester.TimeoutDelegatingHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken) in /home/laura/scratch_pad/Ocelot/src/Ocelot/Requester/TimeoutDelegatingHandler.cs:line 30
         at Ocelot.Requester.MessageInvokerHttpRequester.GetResponse(HttpContext httpContext) in /home/laura/scratch_pad/Ocelot/src/Ocelot/Requester/MessageInvokerHttpRequester.cs:line 29
      Setting error response for request: GET /ocelot/posts/askdj
dbug: Ocelot.Errors.Middleware.ExceptionHandlerMiddleware[0]
      RequestId: 0HNKECIQOAUK4:00000001, PreviousRequestId: -
      Ocelot pipeline finished
info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
      Request finished HTTP/1.1 GET http://localhost:5555/ocelot/posts/askdj - 502 0 - 58.9493ms

[lol768]

HttpExceptionToErrorMapper maps basically every HttpRequestException to a ConnectionToDownstreamServiceError.

Other than looking for the string Request headers must contain only ASCII characters exception message and mapping to a more suitable Error, I wonder if the better fix here is to just drop such characters that wouldn't be considered valid in a request. Given that System.Net.Http.HttpConnection will always complain if it encounters such characters, I'm not sure there's even any point letting it get to the point of the HttpRequester.

[raman-m]

Ocelot is a gateway, and it should not modify either the request or the response data.
Ocelot must forward data as-is. I am surprised that the author questioned this gateway behavior.
The issue may be that Ocelot has changed the status code. If so, this is a minor problem.
The current Ocelot error-handling logic is described in the documentation:

• https://ocelot.readthedocs.io/en/latest/features/errorcodes.html

[raman-m]

@Laura7089 Hello Laura!
Do you still want to discuss this? What is your LinkedIn?

---

Reproduced against the Basic sample on tag 24.1.0 with:

curl -X GET -v 'http://localhost:5555/ocelot/posts/askdj' \
  --header 'Accept: */*' \
  --header 'skull: 💀'

First, could you please attach logs of a direct connection to the downstream endpoint? We need to examine the behavior of the downstream service first.

Second, making requests using the curl tool is not recommended, since Ocelot is not designed to process such requests. Manipulating headers with curl may break the HTTP protocol with a high probability.

The expected behaviour of this should be to return a 4XX error to the client.

Why do you think so?
Ocelot should return the response from the downstream service without modifying it, including the status code, if it encounters an unknown gateway case that falls outside the current design model (as described here):

• Error Handling | Ocelot Docs

In your case, the downstream service returned a 502 error due to invalid data of header body, and Ocelot correctly forwarded this response to the curl client without changing the status code.

The Ocelot Server Error Responses documentation states:

502 Bad Gateway: If unable to connect to the downstream service.

However, if Ocelot overrides the status code in this scenario, I am open to further discussion....

[raman-m]

First, could you please attach logs of a direct connection to the downstream endpoint? We need to examine the behavior of the downstream service first.

[raman-m]

No it didn't. The .NET HTTP Client threw an exception before it even got anywhere near the point of piping data out of the network and then Ocelot incorrectly mapped that back into a 502.

OK. If Ocelot cannot make a request to the downstream service, I agree this could be a bug. We should either forward the header data as-is or transform it.

However, in my opinion, Ocelot is behaving correctly by generating 502 error. If you want to ensure proper forwarding, you should encode the request body.

[Laura7089]

I unfortunately do not have linkedin.

There is no connection to the downstream service, ocelot fails before being able to forward the request. I'd personally consider it valid behaviour to either return a 4XX to the client without forwarding, or to forward the header exactly as-is to the downstream service (which would probably require some kind of escape of the dotnet HttpClient's invariants), but ocelot doesn't do either of these at present.

[Laura7089]

I'd call this an error handling problem rather than a forwarding behaviour problem.

[raman-m]

🆗 I've investigated the problem, and it seems returning a 502 status breaks HTTP 1.1 when a 502 Bad Gateway is returned instead of the expected 400 Bad Request. I'm going to reopen the bug issue → #2376

RFC 7230 a.k.a. "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", section 3.2, "Header Fields", and especially section 3.2.4, "Field Parsing", describes cases that may arise with data for:

• Requests (where a 400 status is preferred),
• Responses (where a 502 status is preferred),
• User agents (where replacement or interpretation is preferred).

[raman-m]

AI prompt

Given discussion: #2375
How do other gateways behave when proxying a request with invalid data in a header field?

Most other popular API gateways and reverse proxies (NGINX, Envoy, Kong, HAProxy, Traefik, and cloud services like AWS API Gateway) treat a request with invalid data in a header value (e.g., non-ASCII characters like emojis, control characters, or other violations of RFC 7230/RFC 3986) as a client error. They reject it early at the ingress layer with a 400 Bad Request (or similar 4xx) response — without attempting to proxy the request to the downstream/upstream service.

This is the expected and secure behavior: the malformation is the client's fault, so it should never surface as a "server/downstream" error like Ocelot's 502 Bad Gateway.

Specific Behaviors by Gateway

• NGINX (and derivatives like OpenResty):
  Rejects the request with HTTP 400 Bad Request. Error log typically shows "client sent invalid header line".
  Header values are strictly limited to printable ASCII + space + horizontal tab; non-ASCII, NUL, LF, CR, etc. are invalid.
  The directive ignore_invalid_headers on (default) discards some malformed headers, but severe violations (like the emoji case) cause an immediate 400. NGINX does not forward them downstream or return a 5xx.

• Envoy (used standalone or in Istio):
  Enforces header validation (via header_validators or protocol options). Malformed headers (invalid ASCII/control chars) result in rejection, usually 400 Bad Request.
  Older versions had an edge case over HTTP/2 where it could return 503 (with "UR" flag) without proxying, but this was addressed in later releases. Envoy explicitly documents http1.invalid_characters as a reason for rejection.

• Kong (built on NGINX/OpenResty):
  Inherits NGINX's validation rules. Malformed/invalid headers (non-ASCII, periods/underscores in names unless configured otherwise) are rejected or stripped, resulting in 400 Bad Request. No proxying occurs.

• HAProxy:
  Very strict by default. Returns 400 Bad Request for invalid characters in headers/URIs (per RFC 3986/7230). You must explicitly enable option accept-invalid-http-request to relax this — and even then it only allows specific edge cases. Blocks control chars, non-ASCII, etc., at the frontend.

• Traefik:
  Follows standard HTTP validation as a modern gateway/router. Malformed requests (invalid headers) are rejected with 400 Bad Request before any routing/proxying. No documented cases of passing through or returning 5xx for client header errors.

• Cloud gateways (AWS API Gateway, Azure API Management, etc.):
  Use built-in request validators and return 4xx errors (often 400 Bad Request or specific validation errors) for malformed headers. They do not proxy invalid requests downstream.

Why This Differs from Ocelot

In the linked discussion, Ocelot's .NET HttpClient throws HttpRequestException: "Request headers must contain only ASCII characters" while building the outbound request. Ocelot's error handler then maps this to ConnectionToDownstreamServiceError → 502 Bad Gateway. Other gateways validate incoming requests before any proxy attempt, so the error stays a clean client 4xx.

Bottom line: The industry-standard behavior is a 400-level rejection at the gateway edge. This avoids leaking internal exceptions, prevents misleading "server error" status codes, and aligns with HTTP spec expectations for malformed client input. If you're building or configuring a gateway, early validation (or optional sanitization) is the norm.

[raman-m]

Opened issue #2376

• Matched requests that contain invalid header values (eg with emoji) return a 502 to the client #2376

[raman-m]

Grok Conversation: https://x.com/i/grok/share/2db32aa8c86a4ef99c51a0d5f8995f8f

[nhmatsumoto]

#2381

[raman-m]

Please be patient, hot cowboy...