- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 23 Jul 2009 10:15:41 +1000
- To: Adrien de Croy <adrien@qbik.com>, Henrik Nordstrom <henrik@henriknordstrom.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
I had a quick look through the drafts, and found only one place where "requested resource" means anything other than "the resource identified by the target-URI (regardless of conneg)": p3 3.2.1: > Content-Encoding may be used to indicate any additional content > codings applied to the data, usually for the purpose of data > compression, that are a property of the requested resource. There is > no default encoding. Here, conneg does (obviously) need to be taken into account (and I've created <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/183> to track this). Did I miss any? In other places where "requested resource" is used I think it is appropriate and switching to "requested representation" (or whatever) would be a mistake; e.g., the last-modified time *is* a property of the resource as a whole, not a specific representation. We do have a related open issue here, tangentially: <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/107 >. The only one where I had to stop and think was in p2 3.2.1 (semantics of 200 for a GET, as H points out); however, that's probably dependent upon the resolution of <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/69 > (which accounts for many of the surviving uses of "variant", BTW). I've put a note in #69 to have a look at p2 3.2.1 to revisit this section as part of that issue's resolution. If you can find other places like that, please add them (or send to me). I agree that conneg would benefit if it were mentioned that it's scoped to a requested resource. All of that said, I'd very much like to see us take a systematic approach to determining the scope (server/resource/representation/ response/etc.) of metadata in the spec, because IME it's often been misinterpreted, and sometimes led to interop problems. WRT "variant" -- that issue has not yet been closed, I think the editors are planning to work on it soon. See: <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/109 >. Cheers, On 22/07/2009, at 8:45 AM, Adrien de Croy wrote: > > how about... > > call it a response. That way we don't make any assumptions about > anything nor set any limitations. You make a request, and you get a > response. The response may have changed or not since last time. > The response may vary on Accept-* headers. The response may be > cached. The response may have been generated at a time specified in > a Last-Modifed header. The response may be the content of a file > whose location matched the path part of the requested URI. Or it > may not. The server can choose any response it wishes without any > restriction. > > This is basically the reality anyway. > > To distinguish between the entire response message and the part of > the message that is deemed to be "transferred", we could add some > other noun to refer to the content (+ attributes) or refer to the > response message as just that - the response message. > > Just an idea. > > Adrien > > > Henrik Nordstrom wrote: >> The "resource" discussion again highlighted the fuzziness on what >> "requested resource" really means. >> >> When reading the specs again I can only agree that it's still quite >> fuzzy, but for other reasons. The way "requested resource" vs >> "representation" is currently used confuses matters a bit. >> >> Intuitively "requested resource" should refer to the resource >> identified >> by the Request-URI. But in fact it's not.. >> >> To me it seems that quite many of the places which today say >> "requested >> resource" maybe should say "requested representation" (if one can say >> anything like that) to align them better with the language used for >> server driven content negotiation, or perhaps we should use the term >> "variant" consistently pretty much anywhere we say "requested >> resource" >> or "selected representation". But neither is good if there exists >> resources with no representations associated... >> >> If not that then the concept of "requested resource" and language >> used >> for describing server driven content negotiation both needs to be >> adjusted/clarified to connect them together. >> >> Some examples: >> p3 4. Content Negotiation >> >> "content negotiation" -- the process of selecting the best >> representation for a given response when there are multiple >> representations available. >> >> p3 4.1 Server-driven Negotiation >> >> ... select a representation ... >> >> etc, quite consistent use representation to identify what was >> selected >> and acted upon. Oddly this chapter talks very little about resources >> however.. >> >> However, in other areas "requested resource" or even >> "variant" (wasn't >> variant supposed to be killed some time ago?) is used for referring >> to >> pretty much the same thing. For example >> >> p4 6.5 If-Unmodified-Since >> >> If the requested resource has not been modified since ... >> >> p4 6.6 Last-Modified >> >> ... the variant was last modified. >> >> p2 8.2.1 200 OK >> >> GET & HEAD ... the requested resource ... >> >> >> >> While in some other areas "requested resource" seems to refer to the >> "resource" identified by the URI, regardless of any content >> negotiation >> taking place. >> >> And yes, Server driven content negotiation IS confusing to >> terminology >> as it causes the notion of a resource to be quite twisted and in >> reality >> is often implemented as several independent resources sharing the >> same >> URI... >> >> Sorry, head a litte dizzy now trying to sort some sense out of these >> terms when content negotiation is used.. can't really say I see a >> light >> yet. >> >> Regards >> Henrik >> >> >> > > -- > Adrien de Croy - WinGate Proxy Server - http://www.wingate.com > > -- Mark Nottingham http://www.mnot.net/
Received on Thursday, 23 July 2009 00:16:26 UTC