[basex-talk] HTTP response and raising error()
Hi, Nothing major but I was wondering what the thinking was behind returning a 400 when fn:error is raised. Basically that says client, your mistake not mine where in most cases I guess a 500 would be more appropriate. Where is this decided (RESTXQ?) and is there an easy way to change the status when fn:error is used? Of course I can always catch at the highest level and then decide which HTTP status to return but I'm not sure if I want to wrap all REST calls in try / catch. -- --Marc
Re: [basex-talk] HTTP response and raising error()
Ah, ok. Didn't know about the third argument. I didn't realize that an int as $error-object would be interpreted as returning that as status code. Is this documented? I mean how BaseX deals with the third argument? I couldn't find it. The spec leaves it open to implementations. --Marc On Thu, Aug 13, 2015 at 3:37 PM, Dirk Kirsten d...@basex.org wrote: Hi Marc, I agree, I think 500 would be more in line with the HTTP status code definitions.. It wasn't really an issue for us in our commercial projects ever (as we mostly send custom status code) and I guess this is why no one cared/noticed, but it would be cleaner to use 500 by default. By the way, you can define the status code easily by using the third argument of the error function: fn:error( xs:QName('error'), message, 500) However, as it would be a breaking change it might be wise to delay the switch until BaseX 9. Or, of course, there are indeed some reasons why this is 400. Cheers Dirk On 08/13/2015 03:06 PM, Marc van Grootel wrote: Hi, Nothing major but I was wondering what the thinking was behind returning a 400 when fn:error is raised. Basically that says client, your mistake not mine where in most cases I guess a 500 would be more appropriate. Where is this decided (RESTXQ?) and is there an easy way to change the status when fn:error is used? Of course I can always catch at the highest level and then decide which HTTP status to return but I'm not sure if I want to wrap all REST calls in try / catch. -- Dirk Kirsten, BaseX GmbH, http://basexgmbh.de |-- Firmensitz: Blarerstrasse 56, 78462 Konstanz |-- Registergericht Freiburg, HRB: 708285, Geschäftsführer: | Dr. Christian Grün, Dr. Alexander Holupirek, Michael Seiferle `-- Phone: 0049 7531 28 28 676, Fax: 0049 7531 20 05 22 -- --Marc
Re: [basex-talk] HTTP response and raising error()
Hello Marc, you are correct. This is the advantage if you see the XQuery code Christian writes, you will discover all the undocumented magic things. But I added a little documentation at http://docs.basex.org/wiki/RESTXQ#XQuery_Errors, so you all know how you can return the mighty 418 status code :) Cheers Dirk On 08/13/2015 04:33 PM, Marc van Grootel wrote: Ah, ok. Didn't know about the third argument. I didn't realize that an int as $error-object would be interpreted as returning that as status code. Is this documented? I mean how BaseX deals with the third argument? I couldn't find it. The spec leaves it open to implementations. --Marc On Thu, Aug 13, 2015 at 3:37 PM, Dirk Kirsten d...@basex.org wrote: Hi Marc, I agree, I think 500 would be more in line with the HTTP status code definitions.. It wasn't really an issue for us in our commercial projects ever (as we mostly send custom status code) and I guess this is why no one cared/noticed, but it would be cleaner to use 500 by default. By the way, you can define the status code easily by using the third argument of the error function: fn:error( xs:QName('error'), message, 500) However, as it would be a breaking change it might be wise to delay the switch until BaseX 9. Or, of course, there are indeed some reasons why this is 400. Cheers Dirk On 08/13/2015 03:06 PM, Marc van Grootel wrote: Hi, Nothing major but I was wondering what the thinking was behind returning a 400 when fn:error is raised. Basically that says client, your mistake not mine where in most cases I guess a 500 would be more appropriate. Where is this decided (RESTXQ?) and is there an easy way to change the status when fn:error is used? Of course I can always catch at the highest level and then decide which HTTP status to return but I'm not sure if I want to wrap all REST calls in try / catch. -- Dirk Kirsten, BaseX GmbH, http://basexgmbh.de |-- Firmensitz: Blarerstrasse 56, 78462 Konstanz |-- Registergericht Freiburg, HRB: 708285, Geschäftsführer: | Dr. Christian Grün, Dr. Alexander Holupirek, Michael Seiferle `-- Phone: 0049 7531 28 28 676, Fax: 0049 7531 20 05 22 -- Dirk Kirsten, BaseX GmbH, http://basexgmbh.de |-- Firmensitz: Blarerstrasse 56, 78462 Konstanz |-- Registergericht Freiburg, HRB: 708285, Geschäftsführer: | Dr. Christian Grün, Dr. Alexander Holupirek, Michael Seiferle `-- Phone: 0049 7531 28 28 676, Fax: 0049 7531 20 05 22
Re: [basex-talk] HTTP response and raising error()
Hi Marc, Nothing major but I was wondering what the thinking was behind returning a 400 when fn:error is raised. Basically that says client, your mistake not mine where in most cases I guess a 500 would be more appropriate. The rationale behind this was that a RESTXQ developer can use fn:error functions, which are triggered when the client sends invalid input. But it's true that 500 codes may be more appropriate if the server code is buggy indeed. Unfortunately, it's not really possible to detect if an error was explicitly raised in the XQuery code, or if it was unexpected. Errors starting with XPST usually indicate parsing errors, but even those codes can be manually generated: fn:error(xs:QName('err:XPST0003'), 'Hehe') Of course I can always catch at the highest level and then decide which HTTP status to return but I'm not sure if I want to wrap all REST calls in try / catch. Could you write more about your use case? Do you expect your code to be buggy, or when do errors occur? Christian PS: Dirk may give you another reply on the third argument of fn:error. I'm not sure if it really works (but never forget I'm getting older every day ;)