Re: Location, URI-header, etc.

(My boss man is going to be happy someone is looking at URI.  It's been
quite underdefined.)

OK, so from this point on is how the Spyglass Server 1.01 implements URI.

>Would the URI-header ever be transmitted along with the body of a
>document (in a 2xx response)?

Yes.  Always.

>If so, does it refer to the enclosed
>document?

Yes.

>  How so?

If there were no variants, it's the name of the file.  Like if you asked for
"/initial" (or "/initial.txt") and there was /initial.txt in the file
system, you would get:
URI: </initial.txt>
If there were /initial.html and /initial.txt and you asked for "/initial"
you may get:
URI: </initial>;vary=type, </initial.txt>
or
URI: </initial>;vary=type, </initial.html>
depending on the results on the content negotiation.  (Section 9)

>Or, like Location, does it refer to the place(s)
>you could GET a document just like the enclosed one if you wanted
>it again?

On redirects we send back both URI: and Location:, and they both have the
same thing (except that URI is in <>'s).  If /initial was a directory:
URI: <http://ddubois.spyglass.com/initial/>
Location: http://ddubois.spyglass.com/initial/

--- Implementation off, opinion on
On 200 OKs: Well, kind of.  Except the 'virtual places' it lists all point
to the same physical space that the document was provided from.  Speaking
from a 200 OK mindset, you already have the document, you don't really need
to go seek it out now (maybe later for new versions, but not right now).
The information in the URI: is for caches as I understand it.

>The URI-header may refer to multiple versions of a resource,
>but doesn't indicate which one is in the message.  

Since you say "in the message" I assume you refer to URI:s in 200 OKs.  The
URI item that doesn't vary is the one that explicitly is in the message,
according to our implementation.  The other URI item(s) are ways to get to
the information, but not as "directly".  (There's got to be a better way of
explaining this.)

>How are you
>supposed to tell, by analysing the other headers?  Is there enough
>information?  What, specifically, is the relationship between a
>URI-header and an enclosed entity?

URI identifies the resource.  There may be multiple ways to identify the
resource based on different URL requests and different content negotiation
(Accept-XXX) headers.  If the URI claims that it varies by
type/language/charset/encoding, then supposedly the cache is supposed to
store the type header(s) information
(Accept:/Accept-Language:/Accept-Charset:/Accept-Encoding:) and compare
it/those for equality the next time it gets a request for "/initial" if it
wants to properly know the validity of the document.

This is how I understand it.  But I could be SOOOO far off it isn't funny.
The whole URI/None acceptable area is a big fuzzball IMHO.
-----
Dan DuBois, Software Animal                          ddubois@spyglass.com
(708) 505-1010 x532                     http://www.spyglass.com/~ddubois/

Received on Friday, 1 September 1995 16:05:28 UTC