Can not quit session

I test my standalone WEB application on VPS.
And when I monitored the list of active connection on port 80 (this is my port listening),
I’ve seen many (about 200) connections from one unknown (SPAM!) subnet.
So, I included the simple check when session opens - each session checks ‘Self.remoteaddress’,
and if it is in this spam subnet, then the method ‘self.quit’ runs.
But this had no effect!
When I check ‘netstat -tanp | grep 80’ - the list of connection grows more and more…
Is this a bag? How I can KILL session?
My application has no any GUI elements, it is the service…

Is the app compiled and running as a CGI ?

Your firewall should help protect you from that.

Perhaps the same issue I have here: https://forum.xojo.com/6224-websession-not-quitting

Can you compile with 2012r2.1 and try that? That worked fine for me.

Unfortunately I don’t have a solution for the latest versions of Xojo. If you read my post, you’ll see that the webapp works fine initially, then something triggers the problem and websessions stop automatically quitting or responding to the session.quit command.

If you post your findings it may help us isolate the problem.

FYI I am using Centos/Apache/CGI.

Thanks for help )

  1. My application is STANDALONE
  2. I obviously can set specific firewall rules without problems… BUT this decision does not answer - WHY I CAN NOT KILL the session in my XOJO program ?? XOJO is good instrument, but it costs some money, and I want use its functions without problems!

If you’re getting hit with lots of spam connections, they may be getting created faster than you can quit them… but you say that your app has no GUI, so when someone connects to your app, what URL do they use? (I’m primarily interested in the URI actually if you don’t want to give away your domain or IP address, that’s okay)

Greg, you are right… These connections created very fast !
Can I quit sessions more quick ?
As for URL, these spammers use my IP address
Thank you

Right, but what’s the rest of the URL? /special/… Or /API/…?

If not, you should look into App.HandleSpecialURL, which is designed especially for non-GUI connections. It avoids all of the overhead of HTML, CSS and JavaScript.