89

What HTTP response headers are required to be sent from server to the client?

I working to optimize the HTTP response headers to minimize the HTTP response overhead. I know "overhead" is somewhat exaggerated, but I like a clean output.

I see a lot of websites sending redundant cache headers, etc..

e.g.

It is redundant to specify both Expires and Cache-Control: max-age, or to specify both Last-Modified and ETag.

  • Source
  • HTTP/1.1: Header Field Definitions
Arad Alvand
  • 8,607
  • 10
  • 51
  • 71
Beni
  • 891
  • 1
  • 6
  • 4

2 Answers2

78

It depends on what you define as being required: there are no header fields that must be sent with every response no matter what the circumstances are, but there are header fields that you really should send. The only header field that comes close is Date, but even it has circumstances under which it is not required.

In the parlance of RFC 2119, the term MUST means that something is a requirement of the specification and not meeting the requirement would be invalid. There are no header fields defined by RFCs 7230, 7231, 7232, 7233, 7234, or 7235 that MUST be sent by an origin server in all cases.

The following headers, for example, can be omitted (though you probably should send them):

7.1.1.2. Date

An origin server MUST NOT send a Date header field if it does not have a clock capable of providing a reasonable approximation of the current instance in Coordinated Universal Time. An origin server MAY send a Date header field if the response is in the 1xx (Informational) or 5xx (Server Error) class of status codes. An origin server MUST send a Date header field in all other cases.

Note the last sentence of the quote. The Date header field MUST be sent if the origin server is capable of providing a "reasonable approximation" of the date in UTC, but there is nothing stopping a server from misrepresenting itself.

7.4.2. Server

An origin server MAY generate a Server field in its responses.

3.3.2. Content-Length

Aside from [a finite number of predefined cases], in the absence of Transfer-Encoding, an origin server SHOULD send a Content-Length header field when the payload body size is known prior to sending the complete header section.

On the subject of Content-Length and Transfer-Encoding, note that neither can be sent, in which case the length of the response is "determined by the number of octets received prior to the server closing the connection."

3.1.1.5. Content-Type

If a Content-Type header field is not present, the recipient MAY either assume a media type of application/octet-stream (RFC2046, Section 4.5.1) or examine the data to determine its type.

There are circumstances under which particular headers can be required, for example:

Community
  • 1
  • 1
Whymarrh
  • 13,139
  • 14
  • 57
  • 108
27

It depends on the specifics of the response, but generally, a response from an origin server should have:

  • Date
  • Content-Type
  • Server

and either Content-Length, Transfer-Encoding or Connection: close.

If you want to do caching, add Cache-Control (e.g., with max-age); Expires isn't generally necessary any more. If you want clients to be able to validate, add Last-Modified or ETag.

Mark Nottingham
  • 5,546
  • 1
  • 25
  • 21
  • 2
    Thanks for the answer! But I don't think the "Server"-header is important. It's also a little security protection to avoid this header-entry. Attackers haven't "any" informations like "OS/Webserver/-version". – Beni Feb 03 '11 at 15:31
  • BTW: the default value of the "Connection"-response entry is the value from the requested header-entry "Connection: close/keep-alive"? – Beni Feb 03 '11 at 15:36
  • 1
    Server isn't strictly required, but some clients seem to want it, IIRC. Definitely do cut it down to the bare minimum. WRT Connection: no, it's what the server intends to do with the connection; it chooses which to send. – Mark Nottingham Feb 07 '11 at 06:40
  • would love a reference to a specification so this wasn't just a says-so answer. – algal Apr 24 '13 at 22:18
  • 27
    Strictly speaking, none of them is required; if you look through RFC2616 (and httpbis docs) you'll see that Date can be omitted if the origin server doesn't have a clock; content-type can be omitted (defaults to application/octet-stream) and server is encouraged but not required with a MUST. This is at least partially because we need to be somewhat backwards-compatible with HTTP/0.9, which didn't have headers at all. however, for a response to be useful, it does need some. – Mark Nottingham Apr 26 '13 at 00:27
  • 5
    @algal When it comes from one of the spec writers I think it's okay. – Whymarrh Aug 30 '14 at 21:09
  • I'd be very surprised to see a `Content-Type` header on a `201 No Content` response. – Martijn Pieters Mar 05 '19 at 18:49
  • Date is needed only for Cache-Control. I tested Chrome and Firefox and caching perfectly works without Date header so it can be safely omitted. It's just insane that in spec the header is mandatory. – Sergey Ponomarev Aug 08 '20 at 17:06
  • I sent an email to WG were asked to change MUST to MAY for the Date https://lists.w3.org/Archives/Public/ietf-http-wg/2020JulSep/0142.html – Sergey Ponomarev Aug 31 '20 at 15:18