Bug 11580 - generate Content-Location headers
Summary: generate Content-Location headers
Status: REOPENED
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_dir (show other bugs)
Version: 2.0.39
Hardware: All All
: P3 enhancement with 6 votes (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-08-09 06:20 UTC by Mark Nottingham
Modified: 2008-06-13 09:18 UTC (History)
1 user (show)



Attachments
adds new directive to mod_dir for returning CL on URIs that end on '/'(patch against 2.2.8) (3.55 KB, patch)
2008-06-13 09:18 UTC, Jose Kahan
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Nottingham 2002-08-09 06:20:06 UTC
The Content-Location HTTP header indicates an alternate location for the 
entity associated with a message. This much underused facility could be very 
useful to agents and automated systems like Google, in order to get a richer 
understanding about the relationship between resources.

For example, if mod_dir were to generate a C-L header for requests to "/":
  Content-Location: /index.html
and likewise requests for /index.html:
  Content-Location: /
Google would know that the representations it stores for each are equivalent, 
rather than just assuming so by using a heuristic.

This is a low-cost way to add some intelligence to the Web. Please consider 
adding C-L to mod_dir. Thanks!
Comment 1 André Malo 2003-03-04 15:35:46 UTC
I don't believe, that it's so useful at all. RFC 2616, 14.14 says:

   A cache cannot assume that an entity with a Content-Location
   different from the URI used to retrieve it can be used to respond to
   later requests on that Content-Location URI.

But that is actually, what you want. Further it's probably not desired to send
something like
Content-Location: /cgi-bin/generate-index.cgi

If the resource (say, index.html) is content-negotiated, the Content-Location
will be set anyway (by mod_negotiation, of course).
Comment 2 Mark Nottingham 2003-03-09 05:18:49 UTC
I didn't imply that C-L would have any effect on caches at all, so am confused
by your first remark.

As to the interaction with mod_negotiation, I think that's beside the point; if
mod_dir serves content at one location ('/') that's available at another
('/index.html'), it should insert a C-L header (configurable, of course).
Comment 3 Da’an 2008-03-13 14:50:56 UTC
This would also be a smarter way to inform of the preferred absolute URI. Some prefer their websites to be access from www.example.tld, where others prefer having it shortened to example.tld.

If I were to prefer www.example.tld, I would normally do a 301 redirect for anyone not accessing my website from the www. prefix domain. Instead, what I should do is to inform users and search engines that my preferred URI for this resource is Content-Location: http://www.example.tld/whatever. When accessed from www.example.tld, a realative URI would suffice.

This could maybe be added as a option to mod_negotiate, as that module is used when generating the Content-Location. (I think?)
Comment 4 Jose Kahan 2008-06-13 09:18:06 UTC
Created attachment 22124 [details]
adds new directive to mod_dir for returning CL on URIs that end on '/'(patch against 2.2.8)

This patch adds a new directive to mod_dir for returning the Content-Location for URIs that end in '/'. The feature is turned off by default and can be used together with mod_setenvif.

Description:	Returns the Content-Location for URis that end in '/'
Syntax:	        DirectoryRevealContentLocation on:off [env=var]
Default:	DirectoryRevealContentLocation off
Context:	server config, virtual host, directory, .htaccess
Module:	mod_dir


An example on making the C-L return conditional to the User-Agent:

BrowserMatch lwp reveal-cl
DirectoryRevealContentLocation on env=reveal-cl

I'll resubmit it against 2.2.9 and trunk in a couple of days. There shouldn't be too much change.

-jose