HandleSpecialURL (3 Bugs)

Is there a way to keep a standalone web app open after HandleSpecialURL has handled the request? I have a number of apps from Real Studio that use to stay running after handling the SpecialURL handler, and now they close immediately after handling the url (yes true is being returned.) For cgi/per-request apps this isn’t an issue, but it’s a showstopper for standalone webapps at the moment on my end, because the output redirects back to a session within the standalone webapp.

By the way I managed to get around the Reqeust.Entity issue (known bug) not returning the POST results from HandleSpecialURL using the System Environment…

Just found a 3rd HandleSpecialURL bug…


Docs state that /special/ (which I’ve always used) or /api/ can be used. the API path always returns an error, where special works perfectly (except for the immediate termination of the standalone web app after the URL has been handled).

Edit: Perhaps the /api/ path is ‘broken’ on windows? just worked on the linux box. arghhh

Standalone apps should not be closing unless there’s a crash or exception. If you want to be sure, you can put app.AutoQuit = False in the App.Open event. I’m not aware of any bugs with /api, so please file a bug report.

I use standalone web apps on Windows and special urls and they never cause the app to quit. Remember that the special urls dont get caught in the unhandled exception event so you need to do any error handling and reporting such in your method for the special urls.

They should get caught in App.UnhandledException. If they don’t, that’s a bug.

Ok I was thought I was told in a previous post that special urls dont get caught by the unhandledexceptions event and that the error was returned to the browser directly. Thanks for clarify this.

The Stripe payments demo is available here in the forums and displays the crash after handling (literally only using Request.Print (“status”) ) the request, and returning true. If I return false, the webapp stays going, but never gets handled by HandleSpecialURL. I tried commenting all code out and only returning true in HandleSpecialURL and it closes/quits immediately after true is returned. HandleSpecialURL isn’t required to keep the demo running on a server (as cgi), but I’d like it to be an option for those who need it in standalone web builds. (Maybe Windows only bug?) Which is why I posted the demo for others to try. I’ve noticed if you load another page with the main going (two browser instances of the webapp) and one handles the specialurl, the webapp will continue running until the the second (tried with more instances.), or All have gone through the specialurl. If it was an app exception it should raise after the first occurrence and crash the other running occurrences?

I use HandleSpecialURL for SiriPort (now members only community)
Old site at:

To replicate Siri for iOS (all devices) and Android 100% identical (but better) plus more cool stuff like home automation and stuff Apple hasn’t done yet, like “find my child” from Siri, and early disaster/notifications where Siri takes over the phone to wake it and notify you of impending weather (obnoxiously if she needs to until you pay attention):-). After reaching 700,000+ daily users from around the world, the 2 servers began bogging and new load handlers had to be put in place for load distribution and some other performance changes made. Users with Siri already installed on their phones could simply switch from using the gs.apple.com siri servers to connect.siriport.us without installing the new Siri client.

I’ve tried running the Siri server code that works perfectly in Real Studio, and repeatedly it closes the HandleSpecialURL as with the Stripe demo.

According to the Xojo docs, HandleSpecialURL is not handled by WebApplication.UnhandledException and prompts an “Internal Server Error.” (Can be seen by returning False in HandleSpecialURL.) So I think that’s where the confusion lies.

(Maybe Paul hasn’t updated the docs?)

I think I’m doing everything right, but every now and again a small syntax change occurs, or a change in the framework is released; and sometimes I’m unaware of the slight change or the docs contradict what actually happens, and have to relearn the new methodology. I think that’s why I love Xojo… when you start to get comfortable something changes and brings back the spark of interest, excitement, and frustrations. Expect the unexpected :slight_smile: It’s a relationship where you never get too comfortable and lose interest… there’s always something new to learn or relearn.

Fwiw, we try to keep the changes which require code changes to a minimum. Unfortunately there have been a few bugs that have required that in the Web Framework.

No complaints at all about the work that’s done. It’s always for the best in the journey…and I thank you all for the hardwork! I just like to make sure I’m not doing something wrong before I implement a work-around.

Ok. I’ve verified that if an exception occurs in the App.HandleSpecialURL event, it will throw the App.UnhandleException event. I have corrected the docs.