: Is a Server and Date HTTP header really necessary for error or redirecting pages? On practically every URL I visit using the command-line tool CURL, there is always a server identification header

Posted in: #301Redirect #Dates #Http #HttpHeaders #Redirects

On practically every URL I visit using the command-line tool CURL, there is always a server identification header and date header outputted regardless of the status of the request.

For example, on my apache-run server, if I request a page that results in an apache generated permanent redirect, CURL receives this response:

HTTP/1.1 301 Moved Permanently
Date: Mon, 23 Nov 2015 22:24:12 GMT
Server: Apache
Location: example.com/ Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://example.com/">here</a>.</p>
</body></html>

I feel the response can be shrunk to:

HTTP/1.1 301 Moved
Location: example.com/
<!DOCTYPE HTML><html><head><title>Moved</title></head><body><h1>Page Moved</h1><a href="http://example.com">continue</a></body></html>

When comparing the two, I feel if I implement the new 301 response on my server instead of apache's original, then I can save users quite a bit of data if they keep requesting pages that redirect to others.

Additionally, if I can trim down my 404 and 410 error pages headers in a similar manner, then bad bots won't be able to consume as much bandwidth in a small time frame, thereby lowering costs for everyone.

Based on an rfc I read, I believe the Date header is used to help the client determine the freshness of a page in cache.

Since redirecting and error pages are never meant to be cached, I'm just curious if I can strip the Date and Server HTTP header fields from the response before sending the resulting response to the client or will doing so cause other issues (for example, like corrupt browser behavior because of missing header)?