HTTP Response Headers
Response headers are part of server responses, delivered when a client makes a request to a resource.
Edited: 2018-02-25 00:48
HTTP Response Headers are delivered in bulk when a server receives a request by a client. A server will usually respond with a response header and response body. Each header field is separated by the CRLF ([CR][LF]) characters. That is, a single carriage return and a single line feed.
Knowing this allows us to parse the header part of the response. A response header might look like this:
HTTP/1.1 200 OK Date: Fri, 24 Feb 2018 15:30:20 GMT Server: Apache/2.4.18 (Ubuntu) Cache-Control: must-revalidate Last-Modified: Thu, 20 Feb 2018 10:22:03 GMT Expires: -1 Vary: Accept-Encoding Transfer-Encoding: chunked Content-Type: text/html; charset=utf-8
The response header part contains multiple response messages which may be understood by a client, such as a web browser.
To send a single response message you can use a server sided programming language such as PHP.
<?php
header('HTTP/1.1 200 OK'); // Always output headers before content
// Content --->>>
Other languages might have similar ways to send headers.
HTTP Header fields
The HTTP Status field contains a simple status code to identify the type of response. 200 OK is a standard response on first views. Subsequent views or requests might result in a 304 Not modified. Receiving a 304 response will allow the client to load the page from its cache, rather than re-download it from the server.
The date field represents the date and time the response was sent from the server, and does not reflect the date of the actual content. Developers should use last-modified instead.
The Server field usually contain information about the operating system of the server.
Cache-Control, in combination with other fields, controls the caching of a resource.
Last-Modified reflects the date and time the content or resource was last modified. This would typically correspond with a timestamp from a database.
Expires is used to tell clients how long, in seconds, they should store a cached copy without checking for a fresh one. In this case it is a negative value, which should force re-validation, but still allow for caching via Last-Modified.
The Vary field tells a proxy server to store two copies of the resource in its cache. One which is uncompressed, and one compressed. Which one is delivered depends on the Accept-Encoding request field of the visiting client.
Transfer-Encoding is specific to HTTP 1.1, and allows for chunked transferring.
The Content-Type field is used to tell the client the format of the response body, in this case HTML encoded with the UFT-8 character-set.
Manually controlling response headers
In PHP, most headers can be controlled using the PHP header function, but in many cases, this is not needed. Apache also has modules to handle things such as compression, and caching of static resources.
Many response fields are automatically filled out by web servers, especially for static content. The only thing we might need to change manually is character encoding and caching of resources. If some of these fields are unwanted, you may be able to turn them off in the configuration of your web server.
Caching of static resources should automatically be handled by servers, but sometimes you might still need to change the related settings to suit your needs, which can be done by editing the server configuration.
In case of dynamic resources, such as when using PHP or other languages, you may need to specifically code the scripts to handle caching. To do this, you can use Etag header (to check if the script itself was changed), and the if-modified-since header to compare against the timestamp of your resource. If both the if-modified-since and Etag matches, a 304 message is delivered to the client, and the script exits without having to re-generate the entire page.
Content Management Systems should automatically handle caching, but this is not always the case. Check with the manual or support of the system, to find out if caching of resources are properly handled by the CMS.
Tell us what you think: