Discussion:
HTTP response and raising error()
(too old to reply)
Marc van Grootel
2015-08-13 13:06:54 UTC
Permalink
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
Dirk Kirsten
2015-08-13 13:37:14 UTC
Permalink
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
Post by Marc van Grootel
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 van Grootel
2015-08-13 14:33:39 UTC
Permalink
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
Post by Dirk Kirsten
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
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
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
| Dr. Christian Grün, Dr. Alexander Holupirek, Michael Seiferle
`-- Phone: 0049 7531 28 28 676, Fax: 0049 7531 20 05 22
--
--Marc
Dirk Kirsten
2015-08-13 14:56:41 UTC
Permalink
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
Post by Marc van Grootel
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
Post by Dirk Kirsten
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
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
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
| 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
Christian Grün
2015-08-13 19:27:23 UTC
Permalink
Hi Marc,
Post by Marc van Grootel
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')
Post by Marc van Grootel
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 ;)
Marc van Grootel
2015-08-13 19:57:00 UTC
Permalink
Hi Christian and Dirk,
Post by Christian Grün
Post by Marc van Grootel
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.
Thanks to Dirk I now know that I can specify response status through the third argument. I assume as I haven't tried it yet. But yes, I still think that assuming the code is wrong would be the better default. Not a biggie though :)
Post by Christian Grün
Post by Marc van Grootel
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?
I was fixing an issue on a REST API for one of our products that uses bx as an object cache. We had cases where a nested object was just added in the main app and bx would not be 100% up to date yet. When such a cache miss occurs I need to call into the main app's API to give me the missing object. This is done via http:send-request to the main app which obviously may fail in various ways too. I use fn:error to signal these conditions. Most of the RESTXQ functions deal with the same object querying and until now I just let the errors bubble up taking advantage of default behaviour. That's where I wanted to let the client know that the request wasn't successful (hence a 500). Probably a bit lazy.
Does that make sense? I'm even older ;)

btw did you already give your Balisage presentation? I read your paper with great interest. Hope it was well received.

Gruß

--Marc
Christian Grün
2015-08-14 07:31:52 UTC
Permalink
Hi Marc,
Post by Marc van Grootel
btw did you already give your Balisage presentation? I read your paper with
great interest. Hope it was well received.
Most credits should be given to Hans-Jürgen Rennau. He was so kind to
include me in the inspiring discussions on the paper, and he also gave
the presentation yesterday [1]. Thanks, Hans-Jürgen!

Cheers,
Christian

[1] https://twitter.com/joewiz/status/631828065140670464

Continue reading on narkive:
Loading...