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

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

From: Roy T. Fielding <fielding@gbiv.com>
Date: Thu, 5 Nov 2020 10:38:33 -0800
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>
Message-Id: <58400266-E730-473E-A1E4-B6894F9C02D9@gbiv.com>
To: Ben Schwartz <bemasc@google.com>
> 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
Received on Thursday, 5 November 2020 18:39:00 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 5 November 2020 18:39:02 UTC