How to test if a webserver is responding to requests

Knowledge Article

Article Number

000280482

Old Article Number

000193513

Article Type

FAQ/Procedural

Title

How to test if a webserver is responding to requests - Remedy AR System Server

Summary

How to test if a webserver is responding to requests - Remedy AR System Server

Product

Remedy AR System Server

Component

AR System Mid Tier

Applies to

Any webserver, the focus would be on jetty but can be used in any webserver

Question

I turned on my web server, the process seems to be running but how can I verify it is actually getting requests and responses?

Answer

This knowledge article may contain information that does not apply to version 21.05 or later which runs in a container environment. Please refer to Article Number 000385088 for more information about troubleshooting BMC products in containers.

Start with the ports

1. If the server should be responding on port 8008 or 8443, run netstat commands on the operating system command line

WINDOWS

netstat -aon | findstr ":443.*LISTEN"

With desired output

TCP 0.0.0.0:443 0.0.0.0:0 LISTENING 9272
TCP [::]:443 [::]:0 LISTENING 9272

This means port 443 is used in ip4 and ip6 interfaces by process id 9271

Linux

netstat -anp | grep ":443.*LISTEN"

With desired output

tcp6 0 0 :::443 :::* LISTEN 9272/java

This means that on ip6 interface port 443 is used by process 23270 with command line java

2. Verify that the process such as "Remedy" or "Tomcat" has same PID as seen in the output of the netstat command. Ex: 9272 in this case

3. If this is not successful, it is possible the process is running but other scenarios such as port conflicts or keystore failures prevent the port from being opened.
4. If this test is successful then test with browsers, curl , wget clients or testHttpClient to test connectivity . Then perform these client test form other points.
This is recommended as sometimes firewalls or proxies prevent this communication even if we know the server is responding locally

Utilities like curl or wget are advised if you have self signed certificates. These utilities can bypass the SSL certificate review (only recommended while testing). Browsers would not be able to do that and can provide a false negative response
The objective of these curl tests is just to get an HTTP response. even though it may be a 500 error

In this example, we know the port is open but an SSL situation prevented an actual http response.

curl -X POST "https://localhost:8443/api/jwt/login" -H "accept: text/plain" -H "Content-Type: application/x-www-form-urlencoded" -d "username=Demo&password=remedy"
curl: (60) SSL certificate problem: self signed certificate

The same example using curl. Using -k flag in curl fixes this issue by ignoring the Certificate problem

curl -k -X GET "https://clm-aus-tnkxn4:8443/api/v1/login"
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
<title>Error 404 Not Found</title>
</head>
<body><h2>HTTP ERROR 404</h2>
<p>Problem accessing /api/v1/login. Reason:
<pre>    Not Found</pre></p>
</body>
</html>

TestHttpClient can also help validate connectivity but it doesn't have an "insecure" flag to avoid certificate validation

to test with TestHttpClient create a simple file such as (called testSSL.txt)

GET https://host:8443/api/v1/login

then execute command such as

java -jar TestHttpClient.jar testSSL.txt --debugHTTP [--debugSSL] 2>&1 > log.txt

log.txt will contain the conversation logs.
for further reference for TestHttpClient use https://communities.bmc.com/docs/DOC-129733

Attachment(s):