What HTTP response headers are required

by

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:

More Related Contents:

  1. Uses of content-disposition in an HTTP response header
  2. Difference between Pragma and Cache-Control headers?
  3. application/x-www-form-urlencoded or multipart/form-data?
  4. Are HTTP headers case-sensitive?
  5. Maximum on HTTP header values?
  6. Custom HTTP headers : naming conventions
  7. What’s the difference between Cache-Control: max-age=0 and no-cache?
  8. ‘Refresh’ HTTP header
  9. What are all the possible values for HTTP “Content-Type” header?
  10. Ideal HTTP cache control headers for different types of resources
  11. Remove http referer
  12. HTTP Range header
  13. Content-Length header with HEAD requests?
  14. Why is Cache-Control attribute sent in request header (client to server)?
  15. How to forward headers on HTTP redirect
  16. How does “304 Not Modified” work exactly?
  17. What is q=0.5 in Accept* HTTP headers?
  18. What is Cache-Control: private?
  19. Standard for adding multiple values of a single HTTP Header to a request or response
  20. What is a full specification of X-Forwarded-Proto HTTP header?
  21. Setting HTTP headers
  22. what characters are allowed in HTTP header values?
  23. What is HTTP “Host” header?
  24. How to evaluate http response codes from bash/shell script?
  25. What does HTTP/1.1 302 mean exactly?
  26. HTTP Cache Control max-age, must-revalidate
  27. Is the Content-Length header required for a HTTP/1.0 response?
  28. What is the proper HTTP response to send for requests that require SSL/TLS
  29. Keep-alive header clarification
  30. S3: How to do a partial read / seek without downloading the complete file?

Leave a Comment