Reading HTTP request headers from a servlet

When a browser requests a web page, it generally sends some additional headers which specify things such as:

• any cookies set for that page;
• which browser or "agent" is making request, along with information about the operating system, installed browser plugins etc;
• the referrer (generally the link that the user clicked on that provoked the request);
• what types of content the browser can deal with.

It's beyond the scope of this tutorial to give all the details of every possibly HTTP request header. And it's actually quite rare to need to read request headers. If necessary, it is recommended that you look at the HTTP protocol specification if you need more details. However, we'll look at a couple of useful cases here by way of example.

Reading a request header

Usually, we'll know the name of the request header that we want to read. In this case, it is a simple matter of calling getHeader() on the HttpServletRequest object that was passed to our doGet()/doPost() method. For example, here is how to read the user-agent header, which essentially tells us which browser (IE, Mozilla, Safari etc) and operating system is making the request:

public final void doGet(HttpServletRequest req, HttpServletResponse res)
    throws ServletException, IOException {
  String agent = req.getHeader("user-agent");
  if (agent != null && agent.indexOf("MSIE") > -1) {
    // Internet Explorer mode
  } else {
    // Non-Internet Explorer mode
  }
}

Note that we should be careful of null values being returned for a given header if it wasn't sent by the client. Note that for a given header, knowing what the actual format of data that we might get can be something of a black art and the user-agent string is one of the worst offenders...!

Some useful headers

Although it is not so usual to need to read request headers, here are some possibly useful cases:

user-agent

As mentioned above, the user-agent can give us the browser (or robot) and version, plus some information about plugins installed. A big problem with this header is the wide variety of formats that different agents use in practice. (See the link for details and examples.)

referer

The referer header (yes, with the word "referrer" misspelt) indicates the link that caused the current item to be requested.

What not to use request heaeders for

You should remember that, like pretty much anything sent in a request to your server, request headers are untrusted data. It is trivial to program a client to set any old string it likes in any request header. You should interpret request headers as a statement about "how the client would like its data", and not as the basis for security-related decisions. The BBC discovered this the embarrasing way when they attempted to withhold iPhone content on the basis of the user-agent string. (For similar reasons, you should take phrases such as "hot link prevention" with a pinch of salt.)