RE: How to express no matching results in HTTP SEARH method?

Roy, you seem to be disagreeing, but then presenting a detailed argument for
the same position you're disagreeing with.  If the search was successfully
performed on a resource, and the result of the search is an empty set,
that's a successful operation (2XX).  If the search could not be performed
for some reason, that's an error (4XX, 5XX).

I'm confused.  Can you clarify why you don't believe that aligns with "if a
search is successfully performed, then HTTP has succeeded"?

(I disagree with you slightly about "find some among many," because the
resource to be searched could be present but empty.  I think the
differentiator is whether the targeted resource exists, regardless of what
it contains.)

-----Original Message-----
From: Roy T. Fielding <fielding@gbiv.com> 
Sent: Thursday, November 5, 2020 1:39 PM
To: Ben Schwartz <bemasc@google.com>
Cc: Stephane Bortzmeyer <bortzmeyer@nic.fr>; Sawood Alam
<ibnesayeed@gmail.com>; Julian Reschke <julian.reschke@gmx.de>; ietf-http-wg
<ietf-http-wg@w3.org>
Subject: Re: How to express no matching results in HTTP SEARH method?

> On Nov 5, 2020, at 9:34 AM, Ben Schwartz <bemasc@google.com> wrote:
> 
> This was extensively debated during the DoH process.  I think the outcome
in RFC 8484 reasonably applies here too: if a search is successfully
performed, then HTTP has succeeded.  If the search result would benefit from
some explanatory metadata, that can be handled in the response body, and the
response format should be rich enough to express it.

I don't care how extensively it was debated within some other WG.
It's not their call. In both cases, that rationale is bogus.

HTTP is an application-layer protocol and the responses must reflect those
semantics within the status code whether the resource is a file, DNS entry,
or search result.
It allows clients to be independent of the resource types and intermediaries
to work without application knowledge.

There are some searches that will return zero results and be considered a
success. That's fine -- it depends on how the search is phrased. Zero
results is not a "not found" error when the search is "find some among
many". 404 would only occur if the request target is the error.

In contrast, failure codes on unsuccessful searches, like bad query syntax,
bad gateways, and timeouts (409, 412, 422, 5xx, etc.), are not successful
responses and must be reflected in the HTTP status code. If the spec says
otherwise, then that spec is in error beyond its own scope.

Specifications that claim to be based on HTTP must adhere to HTTP's
requirements. Specifications that claim something bogus have a conflict that
they must address, either by fixing their spec or by not claiming they are
based on HTTP.

....Roy