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