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

Re: Issue 196, was: #110: how to determine what entity a response carries

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 18 May 2010 14:41:17 +0200
Message-ID: <4BF28AED.4010603@gmx.de>
To: HTTP Working Group <ietf-http-wg@w3.org>
Hi,

i have done some more work on this, and now have reached a stage where 
request-target is only be used when we really mean it. Almost everywhere 
else we now use the new term "Effective Request URI".

See 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/196/i196.7.diff>.

Reminder: there are a few open questions on which I still like to see 
feedback:


#1 request-target "*"

The message syntax allows "*" as request-target, for which no HTTP URI 
syntax is defined 
(<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.html#rfc.section.2.6.3> 
defines "/" and empty path to be equivalent).

On the other hand, special-casing "*" might be tricky, so for *Effective 
Request URI*, we *do* define a serialization (with empty path).


#2 comparing effective request URIs

We currently define comparison to be consistent with normal HTTP URI 
comparison, except that we skip the part that makes empty paths and "/" 
equivalent (due to #1). As far as I can tell, comparison of effective 
request URIs is only relevant in the context of caching; and the 
responses to "OPTIONS *" aren't cacheable anyway, so maybe we don't need 
to special-case this.


#3 new term for "resource identified by effective request URI"

In many places, the spec tries to talk about the URI addressed by the 
request (and historically used request-URI for that). It would be very 
convenient if we defined the term "addressed resource" for that (to be 
defined in 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.html#rfc.section.2.6.3>; 
this might also allow to get rid of a few cases where we currently 
(still) use "requested resource" or "requested variant".

Feedback appreciated,

Julian
Received on Tuesday, 18 May 2010 12:41:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:18 GMT