Re: URI fields in response headers

Roy T. Fielding writes:
>GET http://site/foo?haka+pakeha HTTP/1.0
>User-Agent: Me
>     Accept: text/html;q=1, */*;q=0.5
>     Accept-Language: mi;q=1, en;q=0.9
>     HTTP/1.0 200 OK
>     Content-type: application/pdf
>     Location: http://site/foo.pdf;language=mi;chapters=1-100
>     URI: <http://site/foo>;vary="bytes,chapters,language",
>          <http://site/foo;language="mi">;vary="bytes,chapters",
>          <http://site/foo;language="en-gb">;vary="bytes,chapters",
>          <urn:/NZ/treaties/waikato>;vary="bytes,chapters,language"

Sorry, Roy, you lost me.  Are you saying that the Location header specifies
a URI which uniquely identifies the representation of the resource which is
being returned?  (If so, this is not obvious from reading section 7.1.11.)
Does that also mean that the example I cited in section 7.1.13 is invalid
since the URI header didn't explicitly list every different representation?

Suppose I have 3 versions of foo on my server: japanese plaintext, english
html, and english plaintext.  Would you expect something like this:

GET /foo HTTP/1.0
Accept: text/plain
Accept-language: jp

HTTP/1.0 200 OK
Content-type: text/plain ;charset=iso-2022-jp
Content-language: jp-JP
Location: /
URI: </foo>;vary="language,type,charset",

where those three other URIs will each get a unique representation of the
file?  Or do you only expect URIs for the representations that match the
accept headers?  In either case, I don't see how this is particularly
useful, since the client or proxy won't know the metainformation for any of
the different representation-specific URIs, and therefore won't be able to
correctly return a cached document in response to a request.  In fact, even
if a caching proxy server knew it had *all* the variants, it still couldn't
do it, since it doesn't know the server's qs value to simulate the section 9
content negotiation. 

(And I still don't understand, in the above example, what you would put in a
406 response if the Accept header specified only application/pdf or the like.)

Jim Seidman, Senior Software Engineer
Spyglass Inc., 1230 E. Diehl Road, Naperville IL 60563

Received on Thursday, 15 June 1995 15:24:52 UTC