Chasing errors or misbehavior in the network can be quite a challenge.
Differently to a local application on the DB server, you always have at least 3 players:
- A client to place a request
- some kind of transport layer
- and a server to provide a reply.
This results in a minimum of 3 possible communication layers
- Client <---> Transport
- Server <---> Transport
- Client <---> Server
The last one is probably the easiest to check, while the other
two deal with the same counterpart just from opposite sides.
? Do both ends use the same communication protocol ?
I met more than once that one end expected to use TCP protocol,
but the other side was using UDP or WS (WebSockets) or whatever.
And IF they match ?
? How does the request look?
You may direct a request for a CSP page to a private port
Using 773 instead of 52773 for the IRIS Management Portal
USER>set port="|TCP|777"
USER>open port:(:773):1 write $t
1
USER>use port read what
Now you launch your request from the browser http://localhost:777/csp/sys/UtilHome.cs
and see
USER>write what GET /csp/sys/UtilHome.csp HTTP/1.1 Host: localhost:773 Connection: keep-alive sec-ch-ua: "Chromium";v="142", "Google Chrome";v="142", "Not_A Brand";v="99" sec-ch-ua-mobile: ?0 sec-ch-ua-platform: "Windows" Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7 Sec-Fetch-Site: none Sec-Fetch-Mode: navigate Sec-Fetch-User: ?1 Sec-Fetch-Dest: document Accept-Encoding: gzip, deflate, br, zstd Accept-Language: en-US,en;q=0.9,de-AT;q=0.8,de;q=0.7 Cookie: state-B88AC959-5DBA-11F0-86C0-0242C0A80002=/5jOrv7mM4MMdJCVpOCgtb1j0WTGCB4RZF2IHT4Og+4%3D%3ASYSEXP%3A; state-84BBBB0F-94B2-11F0-BAB4-0242C0A80006=/5jOrv7mM4MMdJCVpOCgtb1j0WTGCB4RZF2IHT4Og+4%3D%3ASYSEXP%3A; state-1E3B3956-9A2D-11F0-AD45-0242C0A8000B=7xLBuIkd9LEHE63vfvhZkekO0SUMlGruyPOWuYCUrt8%3D%3ASYSEXP%3A; USER>
The first lines tell you that your request is using HTML on top of HTTP
That means that HTML is used as the content protocol embedded in HTTP
Your port 773 is bi-directional.
So you might be tempted to compose an HTML wrapped reply and send it back just like
USE port WRITE "<H1>some friendly welcome</H1>",!
As this is not proper HTML and as you miss all required headers and other credentials
for a clean HTTP communication, your Browser may dislike it at least.
Therefore, the next question:
? How does the proper reply look like ?
There is a utility tool in IRIS to examine the reply to some level.
USER>DO $system.CSP.Shell() CSP:USER>>>GET /csp/sys/UtilHome.csp HTTP/1.1 200 OK Content-Type: text/html; charset=utf-8 Set-Cookie: CSPSESSIONID-UP-csp-sys-=3100 3100; path=/csp/sys/; httpOnly; sameSite=strict; Cache-Control: no-cache,no-store Date: Sun, 16 Nov 2025 15:05:37 GMT Expires: -1 X-Frame-Options: SAMEORIGIN <html lang="de" > <head> <title>IRIS - Home</title> <link rel="stylesheet" type="text/css" . . . . . . . . .
You should enable logging for the terminal to study this 120k byte reply in detail
Now it is your next step to dig deeper.
For our example with the CSP page and a browser client, you have 3 options:
- : Use your browser development tools to examine the content
- : Use JavaScript alert() to display some inner invisible content
- : Use JavaScript combined with HTML textarea for more content
At the server end in IRIS, it's a bit easier.
Every CSP page generates a class, which also generates an INT routine
You have the option to add debugging code at all levels
Just as you would do for any normal background job.
Most likely, this is a sequence that is looping until manually released,
or just some kind of individual tracing with ^ERN or a similar approach.
And this works not just for CSP pages but also for %REST processing.
? And what about the Transport step ?
See part 2 of Network Debugging for Beginners
Network Debugging for Beginners - 2