Las cabeceras de respuesta se utilizan para indicar al cliente información adicional acerca del servidor o del recurso solicitado. También trabajan con la estructura <NOMBRE>: <VALOR><CRLF> donde el nombre debe ser un nombre estandarizado que el cliente pueda reconocer, el valor debe ir acorde a la convención establecida para esa cabecera. Veamos las principales.

Content-Type
Indica el tipo del recurso devuelto. Es una de las cabeceras más importantes, ya que permite interpretar correctamente el cuerpo de la respuesta. Su valor es un tipo MIME definido por la lista que mantiene el IANA en http://www.iana.org/assignments/media-types/index.html. Podemos decir que un tipo MIME es lo que en Windows se determina por la extensión de un archivo (.txt, .html, .gif, etc)
Content-Type: text/plain
Content-Type: text/html
Content-Type: image/gif

Server
Se utiliza para identificar al servidor o aplicación que está enviando la respuesta. Sería el equivalente, del lado del servidor, a la cabecera User-Agent del lado del cliente.
Server: Microsoft-IIS/6.0

Location
Esta cabecera se utiliza cuando se envían respuestas con código de redirección, como por ejemplo 302. Esta cabecera indica cuál es la ubicación del recurso. Por ejemplo, si pedimos la home (/) de Google.com, recibiremos una respuesta 302 que nos redirige a la home de Google para el país en que estemos. La cabecera location indica dónde está ese recurso. Su valor es una URL relativa o absoluta.
Location: http://www.google.com.ar/

Set-Cookie
Vimos en el capítulo anterior que las cookies contienen información en el cliente que es reenviada al servidor en cada petición. El servidor utiliza esta cabecera para establecer o modificar la información contenida en las cookies. La sintaxis básica es la misma que utiliza la cabecera Cookie de petición. Se envía una cabecera por cada valor a enviar.
Set-Cookie: usuario=pablo
Set-Cookie: pass=camino

Last-Modified
Indica cuándo fué la última vez que el recurso se actualizó en el servidor. Esto permite hacer peticiones condicionales utilizando la cabecera If-Modified-Since como se vio en el capítulo anterior. Los navegadores almacenan copias locales de los recursos remotos junto con la fecha de modificación para actualizarlos sólo cuando es necesario (Cacheo).
Last-Modified: Wed, 30 Apr 2008 06:46:43 GMT

ETag
Muy similar a Last-Modified, pero en lugar de enviar la fecha de modificación del recurso, envía una etiqueta única asociada a esta versión del recurso. El valor es determinado por el servidor de manera arbitraria. Un recursos puede ser modificado y no cambiar de ETag (por ejemplo, un cambio menor, que no es significativo) o cambiar de ETag y no de fecha de modificación (Si el intervalo entre original y modificación es menor a un segundo). La petición condicional usa la cabecera If-None-Match para indicar que el servidor no le envíe el recurso si tiene el mismo ETag que el cliente guardó con el recurso.
ETag: "bc85caf38daac81:6554"

Estas son las cabeceras de respuesta esenciales para poder entender y analizar una transacción HTTP. Por supuesto hay muchas más y con los usos más diversos. La totalidad de ellas puede verse en la especificación del protocolo. Para profundizar el entendimiento de las mismas, es recomendable realizar capturas con WireShark y observar luego los resultados.