The following reply was made to PR protocol/1014; it has been noted by GNATS.
From: Ka-Ping Yee <[EMAIL PROTECTED]>
To: Dean Gaudet <[EMAIL PROTECTED]>
Subject: Re: protocol/1014: Please, use Content-Location: header?
Date: Tue, 19 Aug 1997 12:25:08 PDT
Dean Gaudet wrote:
>
> Emitting Content-Location for / -> /index.html is not desirable at all.
> Neither is emitting it for /foobar -> /foobar.cgi. Those are not
> just time-saving internal redirects... those are methods of hiding
> implementation of your website.
I agree that it is not necessary to emit Content-Location for
new names produced by multiviews or for all subrequests in general.
I'm specifically requesting that Content-Location be given for
/ -> /index.html, because it is by far the most common manner of
aliasing on the Web that cannot be automatically circumvented,
and this header gives us a fairly easy way to fix that. Reducing
aliasing is important for any application that wants to associate
information with remote documents (such as annotations, ratings, etc.).
In such cases /index.html is exposed to the world anyway, so i
don't think this is in conflict with hiding implementation.
Content-Location: is supposed to show a variant name to make
caching work, and my suggestion is an application of the same idea.
> For example, if you never tack .html onto
> your URLs and you use multiviews everywhere then you can later switch
> selected files to .shtml (SSI), .phtml (mod_php), or .cgi and none of your
> pages will need to be updated to reflect this chance. None of your users
> will notice the change.
This header is not something that would affect the pages in any
event, i believe. No URIs change; this is just a way of providing
extra information to aid caching and identification. RFC 2068 says:
In the case where a resource has multiple entities associated
with it, and those entities actually have separate locations
by which they might be individually accessed, the server should
provide a Content-Location for the particular variant which is
returned. In addition, a server SHOULD provide a Content-Location
for the resource corresponding to the response entity.
Thanks for taking the time to consider this one. Let me know if
this has convinced you at all... :)
Ping
