W3C home > Mailing lists > Public > www-webdav-dasl@w3.org > April to June 2002

RE: error handling, was: Comments on search-00 draft

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sun, 7 Apr 2002 19:55:30 +0200
To: "Lisa Dusseault" <ldusseault@xythos.com>, <www-webdav-dasl@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCEEKAEFAA.julian.reschke@gmx.de>
> From: www-webdav-dasl-request@w3.org
> [mailto:www-webdav-dasl-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Friday, March 29, 2002 6:31 PM
> To: 'Julian Reschke'; www-webdav-dasl@w3.org
> Subject: RE: error handling, was: Comments on search-00 draft
>
>
> > Is there any requirement to marshall search results and error
> > messages in
> > the same body? I'd rather prefer to keep those separated
> > (*if* we are ging
> > to change the error formats).
>
> If by "error messages" you include the kind of error message like "search
> results incomplete", then yes.  I believe the same response body that
> contains the first N <DAV:response> elements should also contain a
> *different* element stating that the results were incomplete and
> the result
> set was truncated by the server.

We currently have that (section 2.4.3), however this format will break if
the search arbiter resource itself also appears as a query result.

Seems that this really requires an extension to the multistatus element.
I'll add this to the issues list. The plan was to have the framework
finished with this draft, but it seems that we need to do some more
changes....

If we do this, I'd also like to rewrite all other error marshalling to be
consistent with RFC3253's error reporting (either 403 or 409, with an XML
response body and a DAV:error element containing the failed
pre/postcondtions). If anybody thinks that complete compatibility with the
old draft is more important, please speak up.


> There may also be a need to report that the results were
> incomplete and the
> result set was truncated at the choice of the client (isn't there a limit
> set in the client request?)  That's important so the client knows the
> difference between receiving 10 results because there were >10 but only 10
> were asked for, and receiving 10 results because there were only
> exactly 10
> results and it just happens that 10 were asked for.
Received on Sunday, 7 April 2002 13:56:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 22 March 2009 03:38:08 GMT