On 4/18/13 4:53 PM, Rob Warren wrote:
Yep! That's the kind of enhancement that required i.e., use as many existing HTTP status codes as possible.On 18-Apr-13, at 8:53 AM, Jerven Bolleman wrote:Many of the current public SPARQL endpoints limit all their users to queries of limited CPU time. But this is not enough to really manage (mis) use of an endpoint. Also the SPARQL api being http based suffers from the problem that we first send the status code and may only find out later that we can'tanswer the query after all. Leading to a 200 not OK problem :(Jerven,I agree that a 200 reply to 'query too complex', 'query too big' or 'query timeout' is not acceptable. However, limits on queries are a tool to keep dumb clients from pounding on the server too hard.A standardized reply / error would be something that I would like to see in that it allows the client to modify its approach to querying the server. It would also be an opportunity to have the server signal to the client what trade-off it is willing to make between sending more triples and increasing the query complexity.Could '413 Request Entity Too Large', '429 Too Many Requests' and '453 Not Enough Bandwidth' be abused here for Sparql endpoints?rhw
-- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen
smime.p7s
Description: S/MIME Cryptographic Signature
