- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 5 Nov 2020 20:37:14 +0100
- To: Michael Douglass <mikeadouglass@gmail.com>, James Fuller <jim@webcomposite.com>
- Cc: "HTTPbis WG (IETF)" <ietf-http-wg@w3.org>
Am 05.11.2020 um 19:05 schrieb Michael Douglass: > I also support not limiting the content type. I can imagine implementing > a search extension to existing XML based protocols. > > RFC5323 Section 3 say's > > Clients can determine which query grammars are supported by an > arbiter by invoking OPTIONS on the search arbiter. If the resource > supports SEARCH, then the DASL response header will appear in the > response. The DASL response header lists the supported grammars. > > Servers supporting the WebDAV extensions [RFC3253 <https://tools.ietf.org/html/rfc3253>] and/or [RFC3744 <https://tools.ietf.org/html/rfc3744>] > MUST also: > > o report SEARCH in the live property DAV:supported-method-set for > all search arbiter resources, and > > ... > > Presumably a WebDAV compliant client knows whether or not SEARCH is > supported as a WebDAV service > > So: > > If it's in DAV:supported-method-set it's WebDAV SEARCH > > If it's in the "Accept-Search" Header Field it's the new SEARCH > > and you can't have both. No need to parse the content. > ... Yes, but... The content type in the payload is supposed to describe the query semantics. I would expect any new use of SEARCH to actually use a payload format that is more specific than text/xml or application/xml. Am I missing something here? Best regards, Julian
Received on Thursday, 5 November 2020 19:37:31 UTC