Loading

CloudHub 2.0: EdgeIngress HTTP_Svrlet errRpt - 400 BAD REQUEST statusCode=17 failed state=MSV_RECEIVING

Veröffentlichungsdatum: Jul 8, 2026
Beschreibung

SYMPTOMS
In the ingress / Edge logs, the failing request shows a sequence similar to the following (values redacted):
  STARTLINE  POST /your-api-path/ HTTP/1.1
  HEADER     Host: api.example.com
  HEADER     ... (all headers parse successfully)
  errRpt - 400 BAD REQUEST statusCode=17 failed state=MSV_RECEIVING
  disconnect cause=DC_LOCAL_PROT_ERROR

Key characteristics:
- The TLS handshake completes successfully (this is not a certificate or TLS-version problem).
- All HTTP headers are parsed; the rejection occurs in the request-receive phase (MSV_RECEIVING).
- No response is returned by the application; the gateway returns a static 400 and closes the connection.

ROOT CAUSE
The hostname the client presents in the TLS handshake (the SNI, or Server Name Indication) does not match the Host header sent inside the HTTP request.

The CloudHub 2.0 ingress requires the SNI and the HTTP Host header to match. When they differ, the request is rejected at the ingress layer with the 400 error described above. This is intended platform behavior and is not configurable.

This is why standard clients succeed while certain clients fail: curl, Postman, and browsers automatically set the SNI to the same hostname used in the request URL, so SNI and Host always match. Some legacy or custom clients instead send an SNI that does not match the Host header, for example:
- a wildcard value (such as *.example.com), or
- the backend or origin hostname (such as an internal application hostname), or
- an empty or hardcoded SNI value.

HOW TO CONFIRM
Capture the client's outbound traffic (a packet capture on the client side is ideal, before TLS termination) and compare, for a failing request:
- the SNI in the TLS ClientHello, against
- the Host header sent in the HTTP request.
If the two do not match, this issue is confirmed. A working client captured the same way will show SNI and Host matching.

Lösung

Configure the client's outbound HTTPS/TLS settings so that it presents an SNI that matches the Host header (the API's fully qualified hostname).

The exact setting depends on the client:
- For IBM CICS on z/OS, review the outbound web service configuration (for example the URIMAP and the associated TLS/SSL client settings) so the SNI sent on the connection equals the target API hostname.
- For custom or in-house HTTP clients, ensure the TLS library is configured to set the SNI to the request hostname rather than a wildcard (*.example.com), a backend hostname, or an empty value.

After the change, resend a test request. A successful call returns HTTP 200 from the gateway.

ADDITIONAL INFORMATION
- This behavior is by design on CloudHub 2.0 and cannot be disabled or relaxed on the platform side; the correction is made on the client.
- The internal error markers (statusCode=17, MSV_RECEIVING, DC_LOCAL_PROT_ERROR) all indicate the request was rejected at the ingress during the receive phase due to the protocol condition above, before reaching the application.
- Because the payload, headers, and TLS certificate are all valid in this scenario, investigation can waste time on the request body or encoding. The distinguishing signal is always the SNI-vs-Host comparison from a packet capture.

Nummer des Knowledge-Artikels

005388694

 
Laden
Salesforce Help | Article