W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 1995

Re: URI fields in response headers

From: Roy T. Fielding <fielding@avron.ICS.UCI.EDU>
Date: Thu, 15 Jun 1995 12:42:57 -0700
To: Jim Seidman <jim@spyglass.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <9506151243.aa12841@paris.ics.uci.edu>
First off, I'm sorry for the lack of progress recently regarding
the HTTP specs -- I seem to be moving from one crisis to another
recently, and so free time has been nowhere to be found.

I am currently at W3C (for the summer) and things will start flying
again just as soon as I can get our machines to work.  The www-*
mailing lists need to be restored (the machine had a breakdown,
mostly due to mass-process+sendmail-queue stress).

Anyway, back to the topic at hand: I actually provided an example
on www-talk last month, but it got swallowed by ListProcessor.
Fortunately, we have a separate archive:

 To: Multiple recipients of list <www-talk@www10.w3.org>
 Subject: Re: Byte ranges -- formal spec proposal
 In-Reply-To: Your message of "Thu, 18 May 1995 06:20:03 +0500."
Brian Behlendorf writes:
> So, does a "byte range" constitute a variation of the object, or a new
> object itself, which deserves a unique URL?  Compelling cases could be
> made on either side, but I think in this situation it truely is a
> variation of the object.  But now we have a problem - the WWW Link Model
> (hi roy!) only lets me link to *objects* (i.e., URL's), not particular
> variations/representations of objects, if I understand things correctly.
> For example, if I have an object that represents my home page, and my home
> page object returns both HTML 2.0 and HTML 3.0 representations of itself,
> there's no way for me to *force* an HTML 2.0 browser to see the HTML 3.0
> representation without giving the HTML 3.0 representation its own,
> un-content-negotiated URL.  Feh.
That is quite correct -- in fact, I came to the same conclusion Tuesday
night (while lying in bed staring at the ceiling, of course) regarding
the need for URL parameters for versioning and content negotiation.
The same applies to byte ranges, page ranges, etc.
> Okay, so here's the problem.  A URL must be able, not required, but able,
> to *completely* describe the request for an object.  In other words, URL's
> must be able to point to particular representations of webbable objects.
> The protocol "method" used.
>                              The additional headers.
Only insofar as they affected the chosen representation.
> In fact, in most
> situations today URL's are used to point to representations instead of
> objects - content providers are simply creating unique URL's to every
> representation.  So, we're not breaking anything fundamental here, it
> seems.  Further more:
> 1) There must be a clear distinction between the part of the URL that
> describes the *object*, and the part of the URL that describes its
> representation.
I'll disagree here -- there only needs to be a distinction between variants;
what that distinction is may vary from parameters to file name extensions.
> 2) User-agents must be able to deal with the part of the URL that
> describes the representation at a higher level - for example, when a user
> goes to "bookmark" the object, they are asked to chose whether they want
> to bookmark the object in general or the particular representation of
> that object.
Yes, UAs need to be able to identify the non-variant part of the URL
(or at least be able to identify what is "more abstract").
> 3) Responses need to indicate which parts of that representation request
> influenced the output, so that caches know what to key on (and don't
> needlessly key on everything in the request.)  I think there's a "vary"
> header proposed somewhere....
Responses need to include a Location: header which defines the exact
variant chosen, and URI headers which define the available variants
for the resource. [Note that this will be a new change to the HTTP spec]
> 4) There must be a defined list of "sanctimonious" headers in HTTP, ones
> which are always part of the request and are *not* modifiable by the
> representation-part of the URL.  For example, User-Agent:, or From:.
> Likewise, content providers should not vary content based on these headers.
Er, well, there's no way to enforce that.  I prefer just requiring that
the UA be informed of what they've received.
> Phew.
> (btw, the CD I'm listening to now seems highly conducive to these kind of
> thought processes - Air, by Pete Namlook, on FAX)
A nice comfy bed works well too.
> So, here's how I think things should look.  The format:
>   http://host/path/to/object?object_arguments;request_headers
*BOING*  phooey.  The answer is in the Relative URL draft.
I will define "the http URL" in the HTTP/1.0 draft (i.e., those parts
left undefined in RFC 1728), and it will be based on the generic-RL syntax.
We can include an appendix on proposed http URL conventions if that is
acceptable to the HTTP WG.
Question:  Why the verbose names?  I preferred "bytes" over "byterange",
and would prefer just "b" even more.  But, I can see where some names
are best left readable and around 4-5 characters:
NOTE: the similarity between the URI: header's vary values and
the parameter names is useful, but not necessary for caching to work sensibly.
In fact, there is no need for any parameter conventions other than
just making it easier for people to read.
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",
It is my personal opinion that multiple byte ranges in a single
URL are not useful and only make life difficult -- multiple requests
are more appropriate.
 ....Roy T. Fielding   Department of ICS, University of California, Irvine USA
     (fielding@w3.org) World-Wide Web Consortium, MIT/LCS, Cambridge, Mass.
Received on Thursday, 15 June 1995 12:48:58 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:42:55 UTC