HTTP/1.0 Header Fields

An HTTP transaction consists of a header followed optionally by an empty line and some data. The header will specify such things as the action required of the server, or the type of data being returned, or a status code. The use of header fields sent in HTTP transactions gives the protocol great flexibility. These fields allow descriptive information to be sent in the transaction, enabling authentication, encryption, and/or user identification. The header is a block of data preceding the actual data, and is often referred to as meta information, because it is information about information. The header lines received from the client, if any, are placed by the server into the CGI environment variables with the prefix HTTP_ followed by the header name. Any - characters in the header name are changed to _ characters. The server may exclude any headers which it has already processed, such as Authorization, Content-Type, and Content-Length. If necessary, the server may choose to exclude any or all of these headers if including them would exceed any system environment limits. An example of this is the HTTP_ACCEPT variable, another example is the header User-Agent.

• HTTP_ACCEPT (or Accept header)
  
  The MIME types which the client will accept, as given by HTTP headers. Other protocols may need to get this information from elsewhere. Each item in this list should be separated by commas as per the HTTP spec.

  Format: type/subtype, type/subtype (e.g. Accept: text/xml,text/html,...).

• HTTP_USER_AGENT (or User-Agent header)
  
  The browser the client is using to send the request.

  General format: software/version library/version.

  The server sends back to the client:
  • A status code that indicates whether the request was successful or not. Typical error codes indicate that the requested file was not found, that the request was malformed, or that authentication is required to access the file.
  • The data itself. Since HTTP is liberal about sending documents of any format, it is ideal for transmitting multimedia such as graphics, audio, and video files. This complete freedom to transmit data of any format is one of the most significant advantages of HTTP and the Web.
  • It also sends back information about the object being returned. Note that the following is not a complete list of header fields, and that some of them only make sense in one direction.


• Content-Type
  
  The Content-Type header field indicates the media type of the data sent to the recipient or, in the case of the HEAD method, the media type that would have been sent had the request been a GET. This field is used by browsers to know how to deal with the data. The client uses this information to determine how to handle a video file or an inline graphic. An example:

  Content-Type: text/html

• Date
  
  The Date header represents the date and time at which the message was originated. An example is:

  Date: Fri, 08 Aug 2003 08:12:31 GMT

• Expires
  
  The Expires field gives the date after which the information in the document ceases to be valid. Caching clients, including proxies, must not cache this copy of the resource beyond the date given, unless its status has been updated by a later check of the origin server.

  Expires: Fri, 01 Sep 2003 16:00:00 GMT

• From
  
  The From header field, if given, should contain an Internet e-mail address for the human user who controls the requesting user agent. An example is:

  From: giannak@csd.uoc.gr

  This header field may be used for logging purposes and as a means for identifying the source of invalid or unwanted requests. It should not be used as an insecure form of access protection. The interpretation of this field is that the request is being performed on behalf of the person given, who accepts responsibility for the method performed. In particular, robot agents should include this header so that the person responsible for running the robot can be contacted if problems occur on the receiving end.


• If-Modified-Since
  
  The If-Modified-Since header field is used with the GET method to make it conditional: if the requested resource has not been modified since the time specified in this field, a copy of the resource will not be returned from the server; instead, a 304 (not modified) response will be returned without any data. An example of the field is:

  If-Modified-Since: Fri, 08 Aug 2003 19:43:31 GMT

• Last-Modified
  
  The Last-Modified header field indicates the date and time at which the sender believes the resource was last modified. The "Last Modified" field is useful for clients that eliminate unnecessary transfers by using caching. The exact semantics of this field are defined in terms of how the receiver should interpret it: if the receiver has a copy of this resource which is older than the date given by the Last-Modified field, that copy should be considered stale. An example of its use is:

  Last-Modified: Fri, 01 Sep 2003 12:45:26 GMT

• Location
  
  The Location response header field defines the exact location of the resource that was identified by the request URI. If the value is a full URL, the server returns a "redirect" to the client to retrieve the specified object directly.

  Location: http://www.csd.uoc.gr/~hy556/notes/HTTP/index.html

  If you want to reference another file on your own server, you should output a partial URL, such as the following:

  Location: /~hy556/notes/HTTP/index.html

  The server will act as if the client had not requested your script, but instead requested http://yourserver/~hy556/notes/HTTP/index.html. It will take care of all access control, determining the file's type, etc.. In this case clients don't do the redirection, but the server does it "on the fly". Important: Only full URLs in Location field can contain the #label part of URL (i.e. fragment), because that is meant only for the client-side, and the server cannot possibly handle it in any way. As an example of actual use, suppose that the "Ask Dr. Marazakis" form has a Yes/No toggle after the question "Did you search the site and read the HTTP tutorial?". The default is No, so if the user doesn't reset this to Yes they will simply be redirected to the HTTP tutorial and their question will not be sent. A simple example in Perl (inside a CGI script), is the following:

      if ($input{'YN'} eq "No") {
        print "Location: http://www.csd.uoc.gr/~hy556/notes/HTTP/index.html\r\n";
      }
      else {
        print "Content-Type: text/html\r\n";
        &Feedback;
      }
  

• Referer
  
  The Referer request header field allows the client to specify, for the server's benefit, the address (URI) of the resource from which the request URI was obtained. This allows a server to generate lists of back-links to resources for interest, logging, optimized caching, etc. It also allows obsolete or mistyped links to be traced for maintenance. Example:

  Referer: http://www.csd.uoc.gr/~hy556/index.html

  If a partial URI is given, it should be interpreted relative to the request URI. The URI must not include a fragment (#label within a document).


• Server
  
  The Server response header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens and comments identifying the server and any significant subproducts. By convention, the product tokens are listed in order of their significance for identifying the application. Example:

  Server: Apache/1.3.27 (Unix)

• User-Agent
  
  The User-Agent field contains information about the user agent originating the request. This is for statistical purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses to avoid particular user agent limitations - such as inability to support HTML tables. By convention, the product tokens are listed in order of their significance for identifying the application. Example:

  User-Agent: Mozilla/5.0 (X11; U; Linux i686) Gecko/20020830