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.
What is the purpose of the HTTP header field “Content-Location”?
Asked Answered
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://www.rfc-editor.org/rfc/rfc7234#section-4.4 and https://www.rfc-editor.org/rfc/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://www.rfc-editor.org/rfc/rfc7231#section-3.1.4.2) Note that Firefox and Chrome do not appear to implement this.
Indeed, HTTP RFC say that there is no defined behaviour of Content-Location for PUT and POST. –
Rowdy
See httpbis: Part 2, Section 6.1: greenbytes.de/tech/webdav/… –
Manvell
How is this different from the "self" link relation? –
Polythene
Content-Location in response to PUT or POST invalidates the cache for the indicated URI. It is in the original HTTP 1.1 spec: tools.ietf.org/html/rfc2616#section-13.10 –
Basia
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.
Also note that datatracker.ietf.org/doc/html/rfc7231#section-3.1.4.2 changes the definition of BASE URL computation so Content-Location cannot be safely used for anything over HTTP because the interpretation depends on user agent following either RFC 7231 or RFC 2616 definition. For details, see datatracker.ietf.org/doc/html/rfc7231#appendix-B –
Eventempered
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.
Please note that the behaviour described in AtomPub regarding completeness of the representation is not backed by the HTTP spec. –
Rowdy
It will be in httpbis: Part 2, Section 6.1: greenbytes.de/tech/webdav/… –
Manvell
Note that RFC2616 is obsoleted by RFC7231 and your quoted text is no longer in RFC7231! See Section 3.1.4.2 –
Changchangaris
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.
RFC 2557 is not about HTTP Content-Location as far as I understand. –
Eventempered
I'm not sure if we're talking about the same thing but the RFC states: This document... b) specifies a MIME content-header (Content-Location) that allow URIs in a multipart/related text/html root body part to reference subsidiary resources in other body parts of the same multipart/related structure. –
Illyricum
As far as I know, RFC 2557 is about aggregate document that contains multiple resources as a single file and the "Content-Location" header of a resource inside such a collection is used to define which URI can be used to refer that specific resource. The aggregate document type defined by RFC 2557 is not generally supported by software known as www browsers. The closest match is "Save as HTML archive" feature of Microsoft Internet Explorer. –
Eventempered
© 2022 - 2024 — McMap. All rights reserved.