What is the purpose of the HTTP header field “Cont

问题:

Confused/inspired by a comment to my question Do search engines respect the HTTP header field “Content-Location”?, I’d like to know, what the exact purpose of the Content-Location header field in HTTP is and how it can be used.

回答1:

In response to a GET request, Content-Location in HTTP can be used when a requested resource has multiple representations available, e.g. multiple languages. The selection of the resource returned will depend on the Accept headers in the original GET request.

Usually, the location specified in the Content-Location header is different to the location specified in the original request's URI.

In response to a PUT or POST request,

• If the Content-Location URI is different than the requested URI, then the cache entry at the indicated URI is invalidated. (see https://tools.ietf.org/html/rfc7234#section-4.4 and https://tools.ietf.org/html/rfc2616#section-13.10)
• If the Content-Location URI is the same as the requested URI, then that indicates to caches that the response to the PUT/POST request is the same as the response that would be received by a 200 response to a GET request at the same location and can thus be cached. (see https://tools.ietf.org/html/rfc7231#section-3.1.4.2) Note that Firefox and Chrome do not appear to implement this.

回答2:

Content-Location HTTP header is supposed to declare unique location of the resource that was used for a response to HTTP GET (e.g. request was GET /frontpage HTTP/1.1, the server may add HTTP header Content-Location: http://domain.com/frontpage.english.msie-optimized informing the user agent that if this specific response is needed later, the provided location should be used because the original location may depend on various things, which should then be explained via the "Vary" header).

However, note that HTTP Content-Location header is problematic in real world usage because different browsers (user agents) handle it differently: http://mail.python.org/pipermail/web-sig/2004-October/000985.html

This is because of RFC 2616 section 14.14 which says that "The value of Content-Location also defines the base URI for the entity". In short, a comforming user agent will compute the BASE URL for the fetched document using the Content-Location header which may result in different relative URLs being used if the fetched document does not define BASE url and real fetched URL and Content-Location differ enough (the "directory"/"path" part of the URL is different).

In addition, I've yet to see any advantage for using HTTP Content-Location (I once hoped that this could be used for hinting about permanent bookmark location in case currently viewed URL was volatile, such as domain.com/news/latest but that doesn't seem to be the case).

My current advice is forget about Content-Location for HTTP but you may use it for MIME email.

回答3:

Section 14.14 of RFC 2616 states:

The Content-Location entity-header field MAY be used to supply the resource location for the entity enclosed in the message when that entity is accessible from a location separate from the requested resource's URI...

This is used in AtomPub (RFC 5023, Section 9.2):

If the creation request contained an Atom Entry Document, and the subsequent response from the server contains a Content-Location header that matches the Location header character-for-character, then the client is authorized to interpret the response entity as being a complete representation of the newly created Entry. Without a matching Content-Location header, the client MUST NOT assume the returned entity is a complete representation of the created Resource.

回答4:

check out RFC2557 at : http://www.faqs.org/rfcs/rfc2557.html for a deeper explanation if you are interested. I'm currently writing about this for a class. It's a little old but still relevant.