- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 28 Apr 2015 07:29:11 +0200
- To: "henry.story@bblfish.net" <henry.story@bblfish.net>
- CC: "Roy T. Fielding" <fielding@gbiv.com>, ashok malhotra <ashok.malhotra@oracle.com>, Mark Nottingham <mnot@mnot.net>, James M Snell <jasnell@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 2015-04-28 00:41, henry.story@bblfish.net wrote: > >> On 27 Apr 2015, at 22:49, Julian Reschke <julian.reschke@gmx.de> wrote: >> >> On 2015-04-27 22:34, henry.story@bblfish.net wrote: >>> ... >>> It is my feeling that the authors of this draf want to do the right thing here, but were worried >>> to come up with a new method name, and favored going with something existing like SEARCH rather >>> than try something new. I was hoping in the previous mail that SEARCH could be redefined to do >>> the right thing. But if it cannot then another method name is welcome. >>> ... >> >> There are already three safe HTTP methods that take a request payload (PROPFIND, SEARCH and REPORT). Some software stacks already know about these (for instance, wrt whether a request can be safely repeated on network failure). There's simply no reason to create yet another one, when, from an HTTP point of view, it does exactly the same thing. > > I think the disagreement is that SEARCH does what we need. To quote Roy Fielding's > answer: > > " In both of those definitions, SEARCH was not a method that scoped its results > to the requested URI. That URI, in fact, had almost nothing to do with the > results, making implementation of the method a significant security risk. " Well, Roy is overstating things. That particular usage pattern depends on the query grammar, and is totally optional in the only grammaer defined in RFC 5323; see <http://greenbytes.de/tech/webdav/rfc5323.html#rfc.section.5.4>. > ... Best regards, Julian
Received on Tuesday, 28 April 2015 05:29:53 UTC