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

From: Julian Reschke <[email-masked]>
Date: Tue, 18 May 2010 14:41:17 +0200

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

---

From: Henrik Nordström <[email-masked]>
Date: Tue, 18 May 2010 20:48:22 +0200

> defines "/" and empty path to be equivalent).

Didn't we reinstate the * rule regarding this? Yes we did. 

http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.html#rfc.section.4.1.2

and a trivial editorial correction needed there:

old:
except as noted above to replace a null path-absolute with "/".
new:
except as noted above to replace a null path-absolute with "/" or "*".

> responses to "OPTIONS *" aren't cacheable anyway, so maybe we don't need 

Agreed. I do not think a special case is needed.

But a note about the "*" mapping maybe, to aid future protocol
extensions.

But this said, it may be worthwhile adding a rule that clients should
not sent a null path-absolute unless they do infact mean the whole
server ("*"), basically restricting such uses to OPTIONS. Most clients
seem to behave like this anyway.

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Tue, 18 May 2010 21:38:17 +0200

> http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.html#rfc.section.4.1.2

We did, but it is phrased as proxy-only, and to be an exception for only 
a few methods.

> except as noted above to replace a null path-absolute with "/" or "*".

Good catch. (more feedback appreciated!)

> But a note about the "*" mapping maybe, to aid future protocol

To where, and for what kind of extensions?

> seem to behave like this anyway.

+1; having the mapping depend on the method name is really strange. Q: 
what does Squid do in this case?

Best regards, Julian

---

From: Henrik Nordström <[email-masked]>
Date: Tue, 18 May 2010 21:58:30 +0200

> what does Squid do in this case?

Squid currently follows 2616 on this.

Regards
Henrik

---

From: Henrik Nordström <[email-masked]>
Date: Tue, 18 May 2010 22:03:12 +0200

tis 2010-05-18 klockan 22:00 +0200 skrev Julian Reschke:
> On 18.05.2010 21:58, Henrik Nordström wrote:
> And it hardwires "OPTIONS", right?

No. The "*" mapping do not exists in 2616. Was resurrected from 2068. 

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Tue, 18 May 2010 22:00:57 +0200

Best regards, Julian

PS: <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/83#comment:7>

---

From: Henrik Nordström <[email-masked]>
Date: Tue, 18 May 2010 22:27:06 +0200

tis 2010-05-18 klockan 22:07 +0200 skrev Julian Reschke:

> Oh, I see.
> 
> So have you ever seen complaints about "*" not working through Squid?

Well, 2616 does not enable clients to even try to request an OPTIONS *
via Squid or any other proxy as there is no forwardable URL form which
translates to OPTIONS *.

I think most applications intending to use OPTIONS * gets quite
satisfied by the result of OPTIONS / which both looks and tastes like
the same thing even if it may differ in some setups, but that's a field
you know much better than me. The use & dynamics of OPTIONS * is not my
field at all.

I only came into this from noticing that 2616 did not enable proxy
clients to request OPTIONS * to be sent to a given server, and then
found that 2068 did have the now resurrected wording which enabeles this
to be done and found no discussions indicating why this text was removed
in 2616.

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Tue, 18 May 2010 22:07:13 +0200

Oh, I see.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 19 May 2010 17:57:42 +0200

On 18.05.2010 21:38, Julian Reschke wrote:
> ...
> ...

Change applied with 
<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/821>.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 26 May 2010 19:49:10 +0200

> (still) use "requested resource" or "requested variant".

For now I have applied the proposed patch to the -latest draft, see 
<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/823>. This should 
make it easier to discuss what's left to do.

We still need to decide on the issues above (and yes, there's feedback 
from Henrik I haven't processed yet).

Best regards, Julian