Displaying HTTP 500 reply error messages (SWI HTTP)

[pic...@alice.it]

I have an issue for reply 500 (internal server error).

In particular, I do not like library('http/http_error.pl') because it removes the error context to add stack trace. However, if I do not use it errors are not displayed at all (only browser's 500) and I have to look at the log file to figure out what's happening.

I have two question:
1) Why not to keep information on error context when using http_error library?
2) How can I have errors displayed (without stack trace), i.e. obtain the same outcome provided by http_error without loading it?

Thank you very much.
Mauro

[janwie...@gmail.com]

On Wednesday, May 15, 2013 12:59:49 PM UTC+2, pic...@alice.it wrote:
> I have an issue for reply 500 (internal server error).
>
>
>
> In particular, I do not like library('http/http_error.pl') because it removes the error context to add stack trace. However, if I do not use it errors are not displayed at all (only browser's 500) and I have to look at the log file to figure out what's happening.

?? In both cases, the server calls print_message(error, Exception) to
get a printable representation of the exception. Errors are of the from
error(ISOTerm, SWITerm), where SWITerm is typically unbound, but may be
bound to a term context(Location, Comment). Location may be set by the
initiator, but normally it is left to the system, which sticks the predicate indicator of the caller there. Library(http/http_error) uses library(prolog_stack) to replace this with a stack trace, which includes
line numbers and a shallow copy of the calling arguments.

Can you give an example where this is less informative than the default?

If you cannot understand the trace, you can use ?- tdebug. which enables
debug mode in all threads and try again. This avoids missing frames due
to last call optimization and missing arguments due to GC. In addition, you can use the flags

backtrace_depth
backtrace_goal_depth
backtrace_show_lines

defined in library(prolog_stack) to control the details of the
backtrace.

> I have two question:
>
> 1) Why not to keep information on error context when using http_error library?

AFAIK nothing meaningful is lost

> 2) How can I have errors displayed (without stack trace), i.e. obtain the same outcome provided by http_error without loading it?

I don't understand this. Errors are normally displayed in the browser with
the 500 error (unless your browser or some proxy replaces them).

Cheers --- Jan

[pic...@alice.it]

Sorry for the lack of details.

I have a handler that basically call load_files/2 on some Prolog sources. What I need is to have informative error messages relative to the source files. This is why I'm not interested in stack trace upstream load_files/2 (where I know there is no problem).

As a first option, I solved by asserting user:message_hook/3 prior to load_files/2 and storing everything to be examined later on. This caused some issues with throw(http_reply(...)), which I posted elsewhere in this newsgroup.

However, I would like the "normal" behavior, i.e. that load_files/2 is free to throw messages (without the above trick with user:message_hook/3).

Sometimes I get confused with exception handling, because instead of appearing in the browser the error message is displayed in the main SWI toplevel window.

I tried with nested catch/3, setup_call_catcher_cleanup/4 but without luck.
When I will have a clear understanding, I will ask you a specific question.

Thank you.
Mauro

[Jan Wielemaker]

On 2013-05-15, pic...@alice.it <pic...@alice.it> wrote:
>
> Sorry for the lack of details.
>
> I have a handler that basically call load_files/2 on some Prolog sources. What I need is to have informative error messages relative to the source files. This is why I'm not interested in stack trace upstream load_files/2 (where I know there is no problem).

Ah, now we are getting somewhere. load_files/2 catches all exceptions
itself and calls print_message/2 on them, continuing the compilation.
The only exception to this rule are errors trying to open the file
(existence, permission). These messages are by default printed to
the user_error stream, and hence you do not see them in the browser
(which only captures current_output). But, if all is configured
ok and you are running a recent version, the http_error library
should not interfere with that. It is supposed to only act on
xceptions thatt are caught by the catch/3 that is guarding the
entire HTTP request handler. See the library prolog_stack (which
does all the work that used to be done my http_errors).

> As a first option, I solved by asserting user:message_hook/3 prior to load_files/2 and storing everything to be examined later on. This caused some issues with throw(http_reply(...)), which I posted elsewhere in this newsgroup.

?? Yes, trapping message_hook/3 is the answer. Actually user:thread_message_hook/3 to avoid
race conditions with other threads that might like to do things differently.
There should be no interference with throw(http_reply(...)), as these are not
supposed to call print_message/2.

There is an implementation for ClioPatria that does all this. It is a bit old
and tight to more of ClioPatrias infrastructure, but it might give you some
hints. You find it here:

http://www.swi-prolog.org/git/ClioPatria.git/blob/HEAD:/components/messages.pl

> However, I would like the "normal" behavior, i.e. that load_files/2 is free to throw messages (without the above trick with user:message_hook/3).

So, that won't work. It it would work, any atempt to load files with errors
would abort the entire compilation process after the first error. Most people
will not get very happy (some would; right now you have to use the message
hook if you want to exit the process on the first error).

> Sometimes I get confused with exception handling, because instead of appearing in the browser the error message is displayed in the main SWI toplevel window.

That is what http_error changes. Note that this is nice, but also reveals
a lot of details to potential attackers. That is why you can load this
library while you are developing and normally leave it out for production
systems.

> I tried with nested catch/3, setup_call_catcher_cleanup/4 but without luck.
> When I will have a clear understanding, I will ask you a specific question.

That doesn't sound like the right direction. I don't have enough context
to point you there though.

Cheers --- Jan