W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2020

Re: Call for Adoption: SEARCH method

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 6 Nov 2020 05:23:42 +0100
To: Michael Douglass <mikeadouglass@gmail.com>, James Fuller <jim@webcomposite.com>
Cc: "HTTPbis WG (IETF)" <ietf-http-wg@w3.org>
Message-ID: <f03f26ef-c1fd-99fa-2238-5b902ac86a80@gmx.de>
Am 06.11.2020 um 04:46 schrieb Michael Douglass:
> On 11/5/20 14:37, Julian Reschke wrote:
>> 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?
> Sorry - I think I replied too high up in the thread.
> Your later message said:
>>> for backwards compatibility with existing WebDAV implementations,
>>> SEARCH requests that use the text/xml or application/xml content
>>> types MUST be processed per the requirements established by [RFC5323
>>> <https://tools.ietf.org/html/rfc5323>].
>> I think this is too restrictive. If it’s not possible to relax the
>> RFC5323 requirements, I would favor using REPORT instead.
>> ...
>> We can relax the requirement to apply only to */xml which has a document
>> element in the "DAV:" namespace (see
>> <https://greenbytes.de/tech/webdav/rfc5323.html#rfc.section.2.2.2>, or
>> even restrict it to the two element names defined there).
> I think my suggestion is a valid way of distinguishing between WebDAV
> search and the new search. Given the existing and proposed headers
> there's no need to parse the content to determine if it's a WebDAV search.

But you need to parse the content at some point of time anyway, right?

> If it's a WebDAV search then that's handled however it's done now (or in
> the future).
> If it's the new search then I don't see that we need to restrict the
> content to NOT have DAV: namespace elements.

First of all, this whole discussion only affects resources that want to
support *both*, that is, implementations of WebDAV SEARCH which want to
implement non-WebDAV uses as well.

Furhermore, the whole distinction between "new" vs "WebDAV" seems to be
weird. The only difference is that for certain specific payloads, the
existing RFC mandates a very specific response format. That's it.
Different request payload formats are totally free to pick what they
need. We are just *relaxing* the requirements.

Best regards, Julian
Received on Friday, 6 November 2020 04:23:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 6 November 2020 04:24:00 UTC