HTTP Headers, Redirects and Response Codes

Any echoed text, HTML outside PHP tags, byte-order mark, or debugging output can begin the response body. Once PHP sends the headers, later changes may trigger 'headers already sent'. Use headers_sent() to diagnose where output began, but fix the output ordering rather than simply adding buffering everywhere. Pure PHP library files commonly omit the closing ?> tag to avoid accidental trailing whitespace. A template should render after the handler has chosen its status and headers. Output buffering may postpone sending bytes, yet it is not a substitute for a clear response structure. Startup errors can also produce output before runtime code runs, so production display settings matter. Keep diagnostic messages in logs when building JSON or download responses.

A 200 response means the requested operation succeeded; a 201 indicates creation when that is the API contract. A 204 response has no body. Use 400 for malformed requests, 401 when authentication is required under the relevant scheme, 403 for denied access, and 404 for an unavailable resource. A 405 response should identify supported methods using Allow. Many APIs use 422 for well-formed input that fails validation, while 409 suits a conflict such as a uniqueness rule. A 500 is an unexpected server failure, not a normal missing field. Choose one consistent API convention and document it. Status codes help clients act correctly; returning every outcome as 200 forces each client to guess what happened from text.

A successful form POST often redirects to a GET confirmation page. This Post/Redirect/Get pattern prevents an ordinary browser refresh from resubmitting the form. A 303 Location response explicitly directs the client to retrieve the target with GET. Other redirect codes differ in permanence and method preservation: 307 and 308 preserve the method, which can be undesirable after a POST. Send a trusted relative or absolute target and terminate processing with exit or a response return boundary. header('Location: ...') does not automatically stop PHP. Code after it can still change data or disclose content. Prefer a fixed application route or an allowlisted destination instead of accepting an arbitrary next URL from the visitor.

A redirect parameter such as next=https://attacker.example can send users to a hostile site while appearing to begin on your trusted domain. Use known route identifiers mapped to internal URLs, or rigorously validate permitted destinations. Be cautious with scheme-relative URLs beginning // and encoded forms of dangerous values. Do not insert raw request text into a header value, including filenames or custom metadata. Header injection and malformed responses can result from inappropriate line breaks or unsafe formatting, even though PHP rejects many invalid header strings. Your application policy should still choose controlled values. Treat security headers as an application design decision: a Content-Security-Policy must match the actual page's script and resource needs rather than being copied blindly from a tutorial.

For JSON, send application/json with a suitable charset and encode the data without notices or extra HTML. For a CSV download, use text/csv and an attachment Content-Disposition with a controlled filename. X-Content-Type-Options: nosniff reduces some content-type guessing in supported browsers. Keep private downloads behind authorization and choose cache controls that do not permit shared storage of sensitive responses. Do not derive Content-Length from a compressed or transformed body without accounting for the actual bytes sent. Streaming a file requires checking its existence and access before headers commit a successful response. If a failure occurs halfway through a stream, you may no longer be able to change the status. Design operational logging for that possibility.

header() can replace a prior header of the same type or add another depending on its replace argument. Some headers may validly repeat, while others should be set once under a clear response policy. Cache-Control defines whether a response can be stored and reused; private and no-store express different policies. A public static asset can have a long cache lifetime with a versioned filename, while an authenticated account page needs more careful treatment. Do not use cache directives as an access-control substitute. Test responses with an HTTP client that shows status and headers rather than inspecting only rendered HTML. Proxies and web servers may add or alter headers, so verify the deployed response when infrastructure behavior matters.

Create an endpoint that returns a JSON validation error with status 422, then a separate successful create response with 201. Set the content type before the body and ensure only encoded JSON appears. The solution uses an error envelope with field messages rather than exposing exceptions. Add method handling with 405 and Allow. Test with a tool that shows headers, including one invalid request and one unsupported method. Next, create a fixed-route 303 form redirect and verify a refresh retrieves the confirmation page rather than resubmitting data. Introduce a whitespace-emitting include in a test environment to identify the headers-already-sent cause, then remove that output.

Combine forms, REST APIs, and security for a complete handler flow.

The PHP header reference explains replacement behavior and the requirement to send headers before output.