For which 3xx HTTP codes is the Location header mandatory?

Question

RFC 2616 defines the Location header as:

The Location response-header field is used to redirect the recipient to a location other than the Request-URI for completion of the request or identification of a new resource
...
For 3xx responses, the location SHOULD indicate the server's preferred URI for automatic redirection to the resource.

AFAIK, for 3xx Redirection codes, the Location header is:

• 300 Multiple Choices : optional
• 301 Moved Permanently : required
• 302 Found : required
• 303 See Other : required
• 304 Not Modified : irrelevant
• 305 Use Proxy : irrelevant (?)
• 306 Switch Proxy : irrelevant (?)
• 307 Temporary Redirect : required
• 308 Permanent Redirect : required

But that's just from personal experience. Is there a standard that defines which HTTP codes require the Location header to be sent?

That is, for which 3xx codes should an HTTP client throw an exception when received without a corresponding Location header?

Answer 1

This question has been asked back in the days when RFC 2616 has still been the authority, so it looked like a fun research project now that RFCs 7230 to 7235 are in place. So, let's see what we've got here.

The Location header is now defined in RFC 7231, section 7.1.2:

The "Location" header field is used in some responses to refer to a specific resource in relation to the response. The type of relationship is defined by the combination of request method and status code semantics.

[…]

For 201 (Created) responses, the Location value refers to the primary resource created by the request. For 3xx (Redirection) responses, the Location value refers to the preferred target resource for automatically redirecting the request.

The section does not confine this header solely to the 3xx-range of status codes. In fact, the only status codes explicitly being mentioned are 201 (Created) and 303 (See Other). No word about this header being actually required by any status code, though.

The purpose of the 3xx-range of codes is now described by RFC 7231, section 6.4:

The 3xx (Redirection) class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request. If a Location header field is provided, the user agent MAY automatically redirect its request to the URI referenced by the Location field value, even if the specific status code is not understood.

The wording suggests that neither the presence nor automatically redirecting to its content is mandatory.

At the time of this writing, the IANA HTTP Status Code Registry is listing the codes 300 through 308 as registered. With one (305) being obsoleted and one being reserved (306), this is leaving seven active codes:

300: Multiple Choices – RFC 7231, section 6.4.1

The 300 code is to be returned if the server is aware of multiple representations of a resource. As of RFC 7231, there is no longer a recommended way to communicate a list of possible representations, though the Link header via RFC 5988 is being mentioned. Regarding the Location header, the RFC has this to say:

If the server has a preferred choice, the server SHOULD generate a Location header field containing a preferred choice's URI reference. The user agent MAY use the Location field value for automatic redirection.

Meaning the Location header is only to be used if the server has a preferred representation. If there is none, the server simply doesn't have such a preference.

It bears mentioning that the Location header by itself is unfit to list all possible representations as it is by its grammar a single-value field that cannot contain a list. Hence, the meaning of

Location: //example.com/a
Location: //example.com/b

is undefined.

301: Moved Permanently – RFC 7231, section 6.4.2

This response code is to let the client know there is an entirely new location for the requested resource: subsequent requests are to be directed at the location specified in the Location header.

The server SHOULD generate a Location header field in the response containing a preferred URI reference for the new permanent URI. The user agent MAY use the Location field value for automatic redirection.

Again, the presence of the Location header is no absolute requirement. The absence of this header would have questionable practicability. The semantics were akin - but not equal - to the 410 (Gone) response: "This resource is has permanently moved to a new, yet unknown location."

302: Found – RFC 7231, section 6.4.3

Originally this is has been specified as "Temporary Redirect" and got renamed in later specs. In contrast to 301 this one cannot (or should not) be cached or used to permanently rewrite URLs. The relevant part of the spec reads:

The server SHOULD generate a Location header field in the response containing a URI reference for the different URI. The user agent MAY use the Location field value for automatic redirection.

I believe the semantics of a missing Location header were pretty much the same as with 301: "This resource is has temporarily moved to a new, yet unknown location."

303: See Other – RFC 7231, section 6.4.4

303 is supposed to be returned in response to a POST request but is applicable to any method. In general, it is meant to let the client know there were a more appropriate representation at a substitute URL or the requested resource cannot be transmitted via HTTP.

In the context of this question, this is a bit of a headscratcher. RFC 2616, section 10.3.4 states:

The different URI SHOULD be given by the Location field in the response.

The relevant section of the newer RFC 7231 seems to simply presume the Location header being present:

the server is redirecting the user agent to a different resource, as indicated by a URI in the Location header field

There is nothing in the errata to clarify this, so I am inclined to assume the position of RFC 2616. The semantics of an absent Location header do differ depending on request method:

• For POST this would be the same as 201 (Created) or 202 (Accepted)
• For any other method, this were identical to 404 (Not Found)

304: Not Modified – RFC 7232, section 4.1

This response is in a way special as it stresses out on the "[indication] that further action needs to be taken by the user agent in order to fulfill the request." It should be understood as a redirect not to a new URI but to a local cache. There is no mention of the Location header in the relevant parts of RFC 7232 at all. In fact, this would make little sense as to my understanding the semantics were something like "the requested presentation of this entity has remained unchainged and you will find it in your local cache at …" That were a great breach of separation of concerns but is not to say Location were not allowed at this place. Still, Content-Location or a Link header with a rel=self part were more appropriate. Former one is receiving explicit mentioning:

The server generating a 304 response MUST generate any of the following header fields that would have been sent in a 200 (OK) response to the same request: Cache-Control, Content-Location, Date, ETag, Expires, and Vary.

305: Use Proxy – RFC 2616, section 10.3.6; RFC 7231, section 6.4.5

This status code has been deprecated as of RFC 7231 due to security concerns (cf Appendix B). Its definition in RFC 2616 reads:

The requested resource MUST be accessed through the proxy given by the Location field.

This implies the presence of a Location header, yet it does not explicitly require it. Omitting this header would have the semantic meaning of "this resource can only be accessed through some proxy."

306: Switch Proxy – draft-cohen-http-305-306-responses-00

Ths code has been introduced as a draft after RFC 2068 has been finalized and already got obsoleted by RFC 2616. To my knowledge, this draft has never reached the status of a recommendation, so this is purely for completeness. The rationale of this draft is to supply proxies with a mechanism to direct clients (temporarily) to other proxies for subsequent requests.

Part of this draft is the introduction of the Set-Proxy header which is to be used in place of the Location header per section 2.2:

In the original HTTP/1.1 spec, the 'Location' header was used to indicate the proxy setting. Its use is DEPRECATED by the 'Set-proxy' header in the context of a 305 response. All new implementations MUST send the Set-proxy header. Implementations MAY send the 'Location' header so as to allow backward compatibility.

Set-Proxy is then required in context of 306 while the Location header is purely optional. As the required Set-Proxy mechanism is meant to replace Location, the absence of latter header introduces no semantic changes.

307: Temporary Redirect – RFC 7231, section 6.4.7

307 got introduced as a result of a semantic change of 302 in HTTP/1.1: While redirects via 302 can change request methods, the redirected request must have the same request method as the original request.

The relevant part of the spec reads:

The server SHOULD generate a Location header field in the response containing a URI reference for the different URI. The user agent MAY use the Location field value for automatic redirection.

Again, Location seems to be optional. For semantic changes due to an absent header, see 302.

308: Permanent Redirect – RFC 7538

Like 307, redirects via 308 are to keep their original request method. One could say 308 were to 301 as 307 is to 302.

From section 3 of the spec:

The server SHOULD generate a Location header field in the response containing a preferred URI reference for the new permanent URI.

So, in summary we have got this situation:

• Implied: 1 (305)
• Optional: 1 (306)
• No mention: 1 (304)
• SHOULD: 6 (300; 301; 302; 303; 307; 308)

That "SHOULD" is to be read in the context of RFC 2119:

This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

This is different from the absolute requirement of a "MUST" or "REQUIRED" (also in that RFC). So in a nutshell: There is no 3xx-class code in which the Location header is mandatory.

It should be noted, that the problem of a missing Location header is not a new one. From another answer:

301, 302, 303, and 307 provide a Location only if the next URL is known. Otherwise, the client/user has to decide what to do next