W3C home > Mailing lists > Public > public-hydra@w3.org > July 2014

Re: Proposed resolution for ISSUE-64 (status codes)

From: Gregg Kellogg <gregg@greggkellogg.net>
Date: Wed, 30 Jul 2014 10:25:20 -0700
Cc: "public-hydra@w3.org" <public-hydra@w3.org>, Andreas Kuckartz <a.kuckartz@ping.de>, Erik Wilde <dret@berkeley.edu>
Message-Id: <799004E6-3D93-4E51-9EF5-A783D6CCA1CB@greggkellogg.net>
To: Ruben Verborgh <ruben.verborgh@ugent.be>
On Jul 30, 2014, at 6:25 AM, Ruben Verborgh <ruben.verborgh@ugent.be> wrote:

> (Copied from another thread for clarity.)
> 
> ISSUE 64: Review HTTP status codes for non-existing / empty fragments
> The current spec says:
> 	 reply with status code 200 OK if the fragment (page) with the given URL exists and is non-empty, i.e., one or more triples match the selector;
> 	 reply with status code 404 Not Found if the fragment (page) with the given URL does not exist or is empty, i.e., no triples match the selector.
> 	 reply with status code 404 Not Found if the selector is invalid i.e., the parameter values are not in the domain of the selector. This is the case if, for instance, a literal is used as subject.
> However, it is argued that 404 might not be the best status code for all cases. 400 might be appropriate for invalid requests that will never have matches (i.e., literal as subject  case 3).

Does this imply that if LD Fragments are used for Hydra Collections that you could not return an empty collection? Returning an empty collection would be useful for describing operations, say, to add something to the collection.

I realize that these are two different things, but if Hydra and LDF are bound, this seems to create an inconsistency.

Gregg

> PROPOSED RESOLUTION
> Remove all MUSTs about status codes,
> add that the server SHOULD return 400 for invalid triple patterns.
> We can then also drop the requirement for servers to respond to HEAD.
> 
> Link: https://github.com/HydraCG/Specifications/issues/64
Received on Wednesday, 30 July 2014 17:25:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:29:42 UTC