Thanks everyone for the advice. We'll go with 503.
On 28 Jun 2011, at 11:28, Michael Hausenblas wrote: > > >> Seriously, I think that >> 413 Request Entity Too Large >> >> would be a good solution: > > > I disagree. Just checked back w/ colleagues on the #rest IRC channel, they > also agree with 503. > > Cheers, > Michael > -- > Dr. Michael Hausenblas, Research Fellow > LiDRC - Linked Data Research Centre > DERI - Digital Enterprise Research Institute > NUIG - National University of Ireland, Galway > Ireland, Europe > Tel. +353 91 495730 > http://linkeddata.deri.ie/ > http://sw-app.org/about.html > > On 28 Jun 2011, at 11:10, Martin Hepp wrote: > >>> >>> Looking for some advice from the community. If we time out a slow-running >>> SPARQL query, what is the most appropriate HTTP status code to return to >>> the client? We had been trying 408, but the problem with that is that some >>> clients (notably Firefox) take it on themselves to keep retrying the >>> request, which isn't really what we want. >>> >>> Should we be returning 500 instead? >> >> What about >> 402 Payment Required? >> >> ;-) >> >> Seriously, I think that >> 413 Request Entity Too Large >> >> would be a good solution: >> >> "The server is refusing to process a request because the request entity is >> larger than the server is willing or able to process. The server MAY close >> the connection to prevent the client from continuing the request. >> >> If the condition is temporary, the server SHOULD include a Retry- After >> header field to indicate that it is temporary and after what time the client >> MAY try again." >> >> 500 Internal Server Error was also my first guess, but this may not stop >> clients from trying again. >> >> Martin >> >> On Jun 28, 2011, at 8:21 AM, Bill Roberts wrote: >> >>> Looking for some advice from the community. If we time out a slow-running >>> SPARQL query, what is the most appropriate HTTP status code to return to >>> the client? We had been trying 408, but the problem with that is that some >>> clients (notably Firefox) take it on themselves to keep retrying the >>> request, which isn't really what we want. >>> >>> Should we be returning 500 instead? >>> >>> Thanks >>> >>> Bill >>> >>> >> >> >
