1

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: http://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: http://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)?

  • Well over a month you most likely save just a few megabytes, a pebble in the ocean. Assets and the amount of server-side requests is where you get most savings, for instance... currently I see you using inline CSS which is generally a bad idea because its not a cachable assest, even with HTML caching, it'll only cache the HTML it already has, so going from one page to a new page will mean having to download the CSS all over again, this alone would save you 100000x more bandwidth than removing a header response that only gets a few hundred hits a month. Also, your JS too :) – Simon Hayter Nov 23 '15 at 22:58
  • If your website is getting a million visitors and a few thousand 404's a day then you may want to use SPDY which will compress your headers, or alternatively just wait until HTTP/2, which should support compression headers. Was going to say reduce the 404 page b/w by removing the template CSS but you done that already :) – Simon Hayter Nov 23 '15 at 23:04
  • Simon, the good news is that 99.9% of the clients have browsers capable of decompressing gzipped data which is what my site serves, and all that data compresses nicely. So instead of serving 10-15KB pages, I'm serving approximately 5KB pages. And yes I use minimal bandwidth possible on bad pages. – Mike Nov 24 '15 at 0:10
  • gzip supports css/js files. If your going to the effort of saving a few bytes on each 404 header response, then wouldn't it make sense to save a few KB on every new page view? Cached assets are not downloaded, period. – Simon Hayter Nov 24 '15 at 0:18
  • Yes but by packing in CSS and JS in the same HTML file, I'm asking users to make fewer round trips to the server. – Mike Nov 24 '15 at 1:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.