HandleURL returns to client Exception message and data. This includes Database errors etc. This could be an attack vector, and I believe is behaving contrary to the documentation by adding this data to the response. I first got this “working” with a bad query, that returned database info the user should not know about.
Tested with 2022R1
How to Reproduce:
Create a new Web project and add the following into HandleURL. Visit the webpage with /mysql etc as per case statements.
select case request.path
dim db as MySQLCommunityServer
dim d as Dictionary
if d.HasKey("FOO") THEN
dim a(0) as string
raise new CryptoException("foo",1)
dim db as new SQLiteDatabase
db.ExecuteSQL("select password from password_table where password = ?","")
You need to try it before you comment because you are misunderstanding. It returns error data to the webresponse and sets the webresponse status to 200. The not specifying new was on purpose to make it raise an exception. Any exception raised in HandleURL will do this
What @DerkJ is saying is that this can (and should) be handled. Just a simple example:
select case Request.Path
dim a(0) as String
a(5) = "foo"
catch e as OutOfBoundsException
Response.Status = 500
Response.Write( "An error has occurred." )
You created a problem that does not exist in well written code. So the only answer is for people that don’t know how to do this the right way (since it’s a public forum) was to say your return value wrong or missing.
Errors should be handled by logging them or another way. But never hand them directly over to the end-user.
So youre saying youve never made a mistake. Once again youre misunderstanding. Try the example and see what it does. As you can see from the sample code nothing is printing to the webresponse or setting status.
Ah, so the problem with the code above is that you’re not returning True to indicate that you’ve handled the request.
Remember, HandleUrl let’s you intercept the first request from a browser to the app and it is that Return True that tells the app that you don’t want a session created and that your code is going to do everything (including setting the response code). If you return False, the default response is a 200 OK because the web app created a session and everything was OK with that process.
The unhandled exception event on app fires when this error occurs. But it still returns the error information to the user that sent the api message regardless of what staus or data is set before this occurs