PHP Response Headers

How it works

header and http_response_code act on the current response in a web SAPI. Unexpected output from an included file can prevent later header changes. JSON encoding should use an explicit error policy so malformed data does not silently turn into an empty or misleading success response. This lab produces a small created-resource representation without storing a real loan.

Run it locally

Save this standalone lab file in a separate local folder. Start a PHP development server on an unused loopback port, for example php -S 127.0.0.1:8090 -t . . Open the shown filename through that server, not a file URL. Exercise GET and POST as described. This is not a POST endpoint on Bhylu, and the built-in development server is not a production server.

php -l response-headers.php
php -S 127.0.0.1:8090 -t .

Download this source as a local PHP lab file. Keep lab files separate from the Bhylu project and production data.

Example

<?php
declare(strict_types=1);

header("Content-Type: application/json; charset=utf-8");
header("X-Content-Type-Options: nosniff");
http_response_code(201);
echo json_encode(["id"=>31,"status"=>"recorded"], JSON_THROW_ON_ERROR);

Expected result

{"id":31,"status":"recorded"}

The HTTP review checks status 201, the JSON content type and the body together. A CLI display of the body alone would not prove the header contract. In a real creation endpoint, use this success response only after the authorised operation has actually committed; the teaching fixture deliberately performs no persistent write.

Requests to check

• GET response-headers.php → status 201.

Use a local browser form or HTTP client. A CSRF token from one session does not authorise a different session. The automated review uses actual HTTP requests, not just command-line output.