PDI outbound REST: HTTP status 0 and Outbound HTTP URL shows "/"

[KeithM203023664]

On my PDI instance, any outbound REST call using [sn_ws.RESTMessageV2] to my AWS API
returns HTTP status 0.

In syslog.list I see:
[AP_Agent_BG] HTTP status: 0 and an empty response body.

In Outbound HTTP Requests for the same transaction, the record shows:

• response_status = -1

• URL = /        (ie no host)

The REST Message has Endpoint set to the full HTTPS URL, and the same URL returns HTTP 200 with JSON when called from Postman and the browser.

This looks like the outbound HTTP client is not using the Endpoint value correctly (host is null), so the call never leaves the instance.  Any ideas what I'm missing or is there a known issue with outbound HTTP on PDIs?  Thanks

[BeingKhan · Accepted solution]

🔍 Deep-Dive Debugging: Outbound REST Calls Returning HTTP 0 on ServiceNow PDI

Problem Signature (Key Indicators)

You are observing all of the following:

• sn_ws.RESTMessageV2.execute() returns HTTP status 0

• syslog.list shows:

  [AP_Agent_BG] HTTP status: 0

• Outbound HTTP Requests record shows:

  • response_status = -1

  • URL = / (host missing)

• Same endpoint works perfectly via:

  • Postman

  • Browser

• REST Message record does contain a valid HTTPS endpoint

This combination is extremely important—it tells us where the failure is happening.

---

🔑 What HTTP Status 0 Actually Means in ServiceNow

In ServiceNow, HTTP status 0 is not a server response.

It means:

❌ The request never left the instance

No DNS lookup
No TCP handshake
No TLS negotiation

So the failure is client-side, before the request ever hits AWS.

---

Step-by-Step Debugging Checklist (In the Correct Order)

✅ Step 1: Confirm You Are NOT Using a MID Server

• Open the REST Message record

• Check “Use MID Server”

  • Must be unchecked unless intentionally required

• If checked without a valid MID → request fails silently

📌 Why this matters:
A missing or offline MID produces exactly this behavior.

---

✅ Step 2: Validate Endpoint Is Fully Qualified (No Hidden Variables)

In the REST Message:

• Endpoint must be absolute, not constructed implicitly

✅ Correct:

https://api.example.amazonaws.com/prod/resource

❌ Risky patterns:

${endpoint}
https://${host}/path

Then check Scripted RESTMessageV2 usage:

var r = new sn_ws.RESTMessageV2('My REST Message', 'post');
r.setEndpoint('https://api.example.amazonaws.com/prod/resource');

⚠️ If setEndpoint() is used, it overrides the REST Message record.
If that value resolves to empty → host becomes /.

---

✅ Step 3: Log the Endpoint Before Execution (Critical)

Add temporary logging before execute():

gs.info('Resolved Endpoint = ' + r.getEndpoint());

If the log prints:

Resolved Endpoint = /

🎯 Root cause confirmed:
The endpoint is being overwritten or nullified at runtime.

---

✅ Step 4: Inspect Outbound HTTP Requests (sys_outbound_http_request)

Open the failing record and inspect:

Field Expected Your Symptom

URL	Full HTTPS URL	/
Response status	200/4xx/5xx	-1
Error message	(if TLS/DNS)	Empty

This confirms:

ServiceNow never resolved the host → no network call occurred

---

✅ Step 5: Check for Malformed Headers (Especially Host)

Common silent killers:

r.setRequestHeader("Host", "");
r.setRequestHeader("Content-Type", null);

🔴 Never manually set the Host header
ServiceNow derives it from the endpoint

If Host becomes blank → URL collapses to /

---

✅ Step 6: TLS / Cipher Compatibility (PDI-Specific)

PDIs are not always on the latest TLS stack.

Check AWS API:

• Does it require:

  • TLS 1.2+

  • Specific cipher suites?

• ServiceNow PDIs sometimes lag behind production clusters

How to test quickly:

• Try a non-AWS HTTPS endpoint (e.g., public echo API)

• If that works → TLS mismatch with AWS

📌 AWS API Gateway often blocks older TLS profiles silently.

---

✅ Step 7: DNS Resolution from the Instance

From Scripts – Background, run:

var socket = new Packages.java.net.Socket();
socket.connect(
  new Packages.java.net.InetSocketAddress("api.example.amazonaws.com", 443),
  5000
);
gs.info("DNS + TCP OK");

If this fails → DNS/network issue on the PDI itself.

---

✅ Step 8: Check IP Restrictions on AWS Side

Even though no request arrives, double-check:

• API Gateway Resource Policy

• VPC Endpoint restrictions

• IP allowlists

ServiceNow PDIs use shared, rotating IP ranges
If AWS blocks them → handshake fails before HTTP response

---

🚨 Known Reality About PDIs (Hard Truth)

PDIs are:

• ❌ Not production-grade network environments

• ❌ Not guaranteed to support all outbound TLS configs

• ❌ Sometimes partially restricted for outbound traffic

This is not a coding issue in most cases.

---

🎯 Most Likely Root Causes (Ranked)

1. Endpoint overridden at runtime and resolving to empty

2. Manual Host header breaking URL resolution

3. TLS / Cipher mismatch with AWS

4. MID Server misconfiguration

5. PDI outbound networking limitation

---

✅ Recommended Final Validation

Create a brand-new REST Message, no scripts, no variables:

• Hardcode endpoint

• No custom headers

• No MID

• Execute via “Test” button

If that still results in URL = / →
✔️ You’ve hit a PDI platform limitation, not a defect in your code.

---

💡 Opinionated Take (From Experience)

If outbound AWS calls are business-critical:

• Do not rely on PDIs for final validation

• Test on:

  • Sub-prod instance

  • Developer instance tied to enterprise cluster

• PDIs are learning sandboxes—not network-accurate replicas

---

[ Please Mark my post as helpful & accept it if you find it valuable. ]

[KeithM203023664]

Thanks.  i hard coded the end point and all working now.  Thanks for the insights.