Subject: #96 Conditional GET text

From: Julian Reschke <[email-masked]>
Date: Fri, 25 Jan 2013 13:49:02 +0100

Hi there,

in the meantime Roy has addressed the main part of the issue, clarifying 
that conditional request header fields apply to many methods other than GET.

I still think it would be good to say more about the default case, though.

Right now, the spec says:

"The new method ought to describe whether it can be made conditional 
(Section 5.2) and, if so, how a server responds when the condition is 
false." -- 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-latest.html#considerations.for.new.methods>

This invites more special cases. Can't we simply state that *all* new 
methods can be made conditional, and describe the default behavior for 
the conditions?

Best regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 25 Jan 2013 06:25:52 -0800

On Jan 25, 2013, at 4:49 AM, Julian Reschke wrote:

> Hi there,
> 
> in the meantime Roy has addressed the main part of the issue, clarifying that conditional request header fields apply to many methods other than GET.
> 
> "The new method ought to describe whether it can be made conditional (Section 5.2) and, if so, how a server responds when the condition is false." -- <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-latest.html#considerations.for.new.methods>
> 
> This invites more special cases. Can't we simply state that *all* new methods can be made conditional, and describe the default behavior for the conditions?

I tried to do that, as much as possible, in section 5 of p4
(Evaluation and Precedence)

http://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p4-conditional.html#precedence

If that is sufficient, I am fine with removing the bit above in
considerations for new methods.

....Roy

---

From: Julian Reschke <[email-masked]>
Date: Fri, 25 Jan 2013 15:46:37 +0100

Looking at 
<http://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p4-conditional.html#precedence>:

"... Other conditional request header fields, defined by extensions to 
HTTP, might place conditions on the state of the target resource in 
general, such as how the If header field in WebDAV has been defined to 
make a request conditional on the presence or absence of a lock [RFC4918]."

Actually, "If", as defined in RFC 2518 and 4918 can put conditions on 
resources other than the target resource, see the "Tagged-list" 
production in 
<http://greenbytes.de/tech/webdav/rfc4918.html#if.header.syntax>) -- 
should we rephrase P4 accordingly?

Best regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 25 Jan 2013 06:58:29 -0800

On Jan 25, 2013, at 6:46 AM, Julian Reschke wrote:

> Looking at <http://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p4-conditional.html#precedence>:
> 
> "... Other conditional request header fields, defined by extensions to HTTP, might place conditions on the state of the target resource in general, such as how the If header field in WebDAV has been defined to make a request conditional on the presence or absence of a lock [RFC4918]."
> 
> Actually, "If", as defined in RFC 2518 and 4918 can put conditions on resources other than the target resource, see the "Tagged-list" production in <http://greenbytes.de/tech/webdav/rfc4918.html#if.header.syntax>) -- should we rephrase P4 accordingly?

WTF? (and I just love the last paragraph in that section)

Sure, rephrase it if you can ... maybe 

  s/ in general/, or a group of resources/

....Roy

---

From: Julian Reschke <[email-masked]>
Date: Fri, 25 Jan 2013 16:05:08 +0100

> WTF? (and I just love the last paragraph in that section)

That just states that RFC 2518 got the syntax wrong (relatively politely).

>    s/ in general/, or a group of resources/

Will do.

Best regards, Julian

---

From: Amos Jeffries <[email-masked]>
Date: Mon, 28 Jan 2013 12:41:02 +1300

On 26/01/2013 4:05 a.m., Julian Reschke wrote:
>>> "... Other conditional request header fields, defined by extensions 
>>> to HTTP, might place conditions on the state of the target resource 
>>> in general, such as how the If header field in WebDAV has been 
>>> defined to make a request conditional on the presence or absence of 
>>> a lock [RFC4918]."
>>>
>>> Actually, "If", as defined in RFC 2518 and 4918 can put conditions 
>>> on resources other than the target resource, see the "Tagged-list" 
>>> production in 

But the above wording implies that future ones MAY do so if they please 
as well.

Is that a desirable implication?

Amos

---

From: Julian Reschke <[email-masked]>
Date: Mon, 28 Jan 2013 09:02:23 +0100

> But the above wording implies that future ones MAY do so if they please

MAY do what?

> ...

Best regards, Juliam

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 29 Jan 2013 00:12:26 +1300

>> But the above wording implies that future ones MAY do so if they please

May define conditionals that refer to resources other than the URL one.

Amos

---

From: Julian Reschke <[email-masked]>
Date: Mon, 28 Jan 2013 12:42:22 +0100

> May define conditionals that refer to resources other than the URL one.

Well, no. The old text did not imply that.

Best regards, Julian