RobotnixAcademy

Week 09 · lesson

HTTP Is a Request and Response Conversation

Once a client reaches an HTTP service, application-layer evidence begins.

HTTP gives us structured requests and responses: method, target/path, headers, body, and status.

Those fields let you diagnose application behavior without guessing from a browser screenshot alone.

Read a request

Supplied request:

GET /status HTTP/1.1
Host: status.robotnix.example
Accept: application/json

Important observations:

  • method is GET;
  • target is /status;
  • host field names the intended HTTP virtual host;
  • client says JSON is acceptable.

Do not infer authentication state or user identity unless other evidence shows it.

Read a response

Supplied response:

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{"service":"status","state":"ok"}

A 200 response indicates that the HTTP server represented the request as successful according to its application logic.

It does not prove every dependency behind the service is healthy unless the endpoint specifically and correctly checks them.

Status codes are evidence about protocol/application handling

A simplified set:

2xx → request handled successfully by the represented HTTP logic
3xx → redirection
4xx → client/request-side class of result
5xx → server-side class of result

Avoid turning these into moral labels.

403 does not mean “hacker blocked.”

500 does not prove “server was attacked.”

They are protocol/application outcomes that need context.

Same network path, different application outcome

Supplied evidence:

DNS → expected address
TCP → handshake success
TLS → handshake success
HTTP GET /status → 503 Service Unavailable

Network connectivity is working far enough for the HTTP response to arrive.

The failure is now higher in the stack.

A useful hypothesis may involve an unavailable application dependency, but you need service logs or architecture evidence to identify which one.

Headers carry metadata and policy

Headers may describe:

  • content type;
  • caching;
  • authorization credentials/tokens;
  • cookies;
  • accepted representations;
  • server behavior; or
  • security policy.

Treat headers as data. Do not paste real authentication tokens into a classroom artifact.

Use synthetic values such as:

Authorization: Bearer REDACTED-FICTIONAL-TOKEN

Lab: correlate request, response, and service log

Request:

GET /status HTTP/1.1
Host: status.robotnix.example

Response:

HTTP/1.1 503 Service Unavailable

Supplied service log:

11:20:03 request_id=rnx-771 path=/status
11:20:03 dependency=db-check result=timeout
11:20:03 response status=503 request_id=rnx-771

Now you can support a more specific claim:

The supplied application log associates request rnx-771 with a database-check timeout and an HTTP 503 response.

Still do not claim the database itself was down globally. The evidence says this application check timed out.

Request IDs help correlate layers

A request identifier can connect:

  • reverse proxy log;
  • application log;
  • dependency call; and
  • response.

Correlation is powerful because one artifact alone may be ambiguous.

But identifiers should be designed to avoid embedding sensitive data.

Test the required function, not only “HTTP responds”

A server can return:

HTTP 200

with the wrong content.

If the required function is:

/status returns JSON field state=ok

then the retest should check that requirement.

The more precise the requirement, the more meaningful the test.

Extend your Web Path Evidence Stack

Add:

HTTP method/path:
Response status:
Expected content/property:
Request ID if supplied:
Correlated service event:
Strongest application-layer claim:
One dependency claim you still cannot make:

Lesson 3 adds TLS identity and trust conditions to the same path.