What is the practical difference between these two?
The HandleURL documentation states “special” is a reserved word so that SpecialURL apps don’t break. Does this mean SpecialURL is now obsolete or does the session-less nature provide benefits in throughput?
Thanks
Eric
Looking into this a bit more, seems like there’s not much one can do without sessions of some sort…
The following code in the HandleURL event fails with a SessionNotAvailable exception:
Function HandleURL(Request As WebRequest) As Boolean
dim WP as new WebPage
WP.TextArea1.text = "Hello world"
WP.Show
Return True
End Function
Indeed the session is not there, you can get requests from HTML pages and other programs, then respond by sending data. SpecialURL which can be called with /Special or /API is convenient for web service apps.
I have used HandleURL for a bundle of things that an app cannot do. For instance serve pictures, fonts, on folders relative to the app, such as 127.0.0.1:8080/pics/myPic.png
I also experimented serving entire HTML sites through it.
Thanks Michael,
Is there any way to start a session and hand the request over to it? It seems the App has a session object.
The following code fails on line 1 with a Not enough arguments got 0 expected 2 error:
Function HandleURL(Request As WebRequest) As Boolean
dim Ses as new Session
dim WP = new Ses.WebPage1
WP.TextArea1.text = "Hello world"
WP.Show
return true
End Function
Can this be achieved?
I want to be able to analise the request before directing it to the appropriate area in my app…
Thanks,
Eric
[quote=190363:@Eric Wilson]Thanks Michael,
Is there any way to start a session and hand the request over to it? It seems the App has a session object.
The following code fails on line 1 with a Not enough arguments got 0 expected 2 error:
Function HandleURL(Request As WebRequest) As Boolean
dim Ses as new Session
dim WP = new Ses.WebPage1
WP.TextArea1.text = "Hello world"
WP.Show
return true
End Function
Can this be achieved?
I want to be able to analise the request before directing it to the appropriate area in my app…
Thanks,
Eric[/quote]
I do not think what you are trying to do in your code can work. Pending Greg’s authorized perspective, what your code seems to want to do is to create a copy of a session that does not exist yet.
That said, what you describe you want to obtain can be done without Session. Check out a thread from not long ago https://forum.xojo.com/6637-receive-post-data-in-a-web-app
Where I share how I do that (May 23 post).
Thanks for the reference Michael,
A browser redirect had occurred to me however I’m building a high performance app which needs to scale.
There should be nothing inherently unstable about my approach since Xojo must be able to start new instances of a session all the time. However I can’t find any docs as to the two parameters it wants or the syntax for passing them…
As an aside, it seems to me that such an approach would also address the issues in the discussion to which you referred.
Does anyone know the syntax to make my code work? Is this possible?
Thanks,
Eric
[quote=190372:@Eric Wilson]Thanks for the reference Michael,
A browser redirect had occurred to me however I’m building a high performance app which needs to scale.
There should be nothing inherently unstable about my approach since Xojo must be able to start new instances of a session all the time. However I can’t find any docs as to the two parameters it wants or the syntax for passing them…
As an aside, it seems to me that such an approach would also address the issues in the discussion to which you referred.
Does anyone know the syntax to make my code work? Is this possible?
Thanks,
Eric[/quote]
Steve, you want to create an new instance of a WebSession that does not exist yet. When your user gets to /Special or /Whatever the app does not create a session. So you cannot have an instance of it. AFAIK the only way a session can be created (and this must be quite an undertaking) is by connecting to the “front door” of the app, so the framework does all kinds of things (looking at user IP, headers, among other things) to create the session, with an ID, that will enable displaying webpages.
When you get to the front door of the app, Session does a fulltitude of things related to the job of serving pages, then when the webpage is sent, yet another full house is necessary for it to make a grand appearance : headers, analysis of the user-agent, various kitchen sinks. SpecialURL and HandleURL are not intended for such a stage. What they do is very basic, very low level input/output intended for API and other tasks where the normal page serving would simply be a mess. To take an example, if I want to use an API as a listener for Paypal, I do not want anything to be sent to it but very precise data conformant to the specs. If I want to serve a Woff font from my app, all I want to do is when HandleURL sees the URL as being /Fonts/myFont.Woff/ it simply prints it, just the same way as it would happen if I was accessing it on a standard web space.
If what you want to do is to be able to add requests to your app, don’t use subdirectories. Use arguments and look for them in Session.URLArgument(“myargument”).
For instance, you can have users access your app as
http://127.0.0.1:8080?page=BarcelonaThen in Session, you can have this, that will display the proper page according to the argument :
Sub Open()
if URLParameter("Page") = "Barcelona" then WebPage11.Show
End Sub
I shall think that solution, much lighter, will cope much better with scaling.
Thanks Michel (sorry for calling you Michael – changing glasses now…),
Machine-to-machine communications are what SpecialHandle was for and for that your reply makes good sense.
However, HandleURL is advertised for handling 404 errors which by definition contain bad URLs. Your solution will work in many but not all cases, because if the part before the query symbol “?” is incorrect, your solution would break. There should be a way for a “front door” to a session to be passed as an answer to a request if our code in the App deems it appropriate.
For example, if a user types “company.com/product” (as marketing people won’t publish a query string) the customer should get “company.com/products” seamlessly without back-and-forth. Likewise, if a user types company.com/bookings or company.com/reservations they should be directed to the same page.
Nevertheless, your answer is good enough for my present purposes, so thanks so much for taking the time to answer.
From the discussion it seems the answer to my original question is that SpecialURL may be obsolete, because I didn’t realise that HandleURL is session-less.
Thanks again
Eric AKA “Stephen”
No problem.
[quote]However, HandleURL is advertised for handling 404 errors which by definition contain bad URLs. Your solution will work in many but not all cases, because if the part before the query symbol “?” is incorrect, your solution would break. There should be a way for a “front door” to a session to be passed as an answer to a request if our code in the App deems it appropriate.
For example, if a user types “company.com/product” (as marketing people won’t publish a query string) the customer should get “company.com/products” seamlessly without back-and-forth. Likewise, if a user types company.com/bookings or company.com/reservations they should be directed to the same page. [/quote]
You handle 404 the very same way I described in the other thread. look at the URL, and decide if it can be sent to the app with the proper argument or to the error page, doing just the seamless stuff you describe. Actually, you can have quite an elaborate redirection scheme, akin to 302 under Apache. Even better, changing by the IP of the visitor or by the time of day…
[quote]From the discussion it seems the answer to my original question is that SpecialURL is obsolete, because I didn’t realise that HandleURL is session-less.
[/quote]
SpecialURL could be considered as obsolete, except you may want to use it for simplicity for an API. Since it has to be called explicitly with /Special or /API, you do not run the risk to have all the attempts of a Russian hacker mess up your HandleURL. And that is no joke, these guys are at it all the time, plus people from all over the world. I have my logs to show for it. These stupid guys will try so many things that will no doubt trip every time HandleURL, whereas SpecialURL will remain immune.
Even so, the browser redirect method is very HTML 1.0-looking, and can increase server loads for large scale apps. I would like to give customers a smoother ride so will file a feature request…
Thanks again,
Eric
Two things of note happened since my last post.
Firstly, on the way to making a feature request, I clicked on the link supplied by Xojo and Firefox gave me an ugly blank page with this message:
“Firefox prevented this page from automatically redirecting to another page.”
… and refused the redirect until I pressed an “Allow” button.
This makes the redirect method a customer experience-breaker.
Then, while I was on my way back here to state this, I typed Xojo: Cross-platform App Development Tool and was given a “Sorry, the page you were looking for cannot be found” instead of a redirect. (A genuine mistake – I should have typed forum.xojo.com).
Maybe Xojo’s web team deem this error page as the lesser of two evils.
Either way, all of our customer experiences could be greatly improved by such a feature request.
From reading this thread I think there may be a basic misunderstanding of the session concept. Maybe or maybe not.
A session is created when a browser makes a connection to the app. They seem to be quite ethereal and come and go. For example, if a user refreshes your web app, a new session is created. They seem to be the underlying connection between the browser and the app. So you can’t just create them. The browser itself does.
You can use a session and execute code in it. But Indont think it makes sense to create a session and then try to tell the browser to use it. The browser has a session already by communicating with your app. Use that session.
I do not pretend that Refresh is the only way to activate the app. Maybe there are more elegant ways to do that.
Now; for the scale, I will question the way you want things done. The normal way to navigate through a web app to specific pages should always be parameters, let alone because that way you do not have to go through convoluted things in HandleURL.
Your idea of systematically using subdirectories through HandleURL seems to be kind of chaotic. HTML1.00 or not, handleURL should never be a standard navigation method. Even if it were fast (which without testing I would bet is kinda slow), and if you found a better method than Refresh, it is not a standard and documented way of running a web app. It should be used IMHO only to solve possible mistype, but admittedly, that should never account for more than a few percentage points of requests.
If scale is your concern, you should stick to documented methods, use parameters, and concentrate your efforts on optimizing standard code. As a matter of general course, anyway, optimization comes when a program works and not as a preamble.
Thanks for your post Jon,
Looks like there’s a session timeout property which can be set to zero to create permanent sessions. Using browser cookie methods to tie the session to the browser is another idea, however that if used alone might create security issues. I guess it’s best to save out using the session timeout event and restore the user once they have re-authenticated.
I don’t know if sessions are created before the HandleURL event fires. I don’t know why they should be if one uses the event to send data.
Cheers,
Eric
I agree with you Michel – all I meant by scale was the additional server load of handling the repeat requests involved in a redirect for very large sites which could have thousands of them for tens of thousands of users, especially when content has been moved around a lot. (i.e. sometimes the developer has little choice with legacy systems.) I think Xojo is great BTW.
So now that I’ve had a chance to read this thread, let’s clear some things up.
Sessions Require JavaScript. There’s no way around that. Using an httpsocket to connect to a web app does not get you a persistent WebSession.
HandleSpecialURL came first, 2011 to be exact, and was in direct response to users wanting the ability to handle RestAPI type requests. If you need session persistence you need to do that yourself. This event is only triggered for /api and /special.
HandleURL was introduced in Fall 2014 and while it mimics HandleSpecialURL, it also adds some things:
A. We reserved a few root URL paths and opened everything else up to developers. Mostly this is for historical reasons.
B. You can intercept a root level request and respond differently (like if a request comes from a googlebot).
Sessions are created after HandleURL.
As I said, using that method should be exceptional, but allow me to doubt very much redirects are the largest part of a server load ever. Apache, or whichever well conceived server software, treats such requests light years faster than anything inside a Xojo Web App with less load than the weight of a butterfly.
When you talk about content moved a lot, we are talking about a web site, right ? Do not confuse a Xojo app and a web space. It is not at all the same thing.
Setting that to zero will make the session expire immediately.
Yeah, don’t use cookies alone. Have the user re authenticate.
Content and apps have converged and are converging with mobile devices.
Further, people want their state information to be preserved and work across devices and for different parts of their lives. Thus ordinary web servers are becoming more and more uneconomic to develop for as content becomes apps and vise-verse.
Also, the Web is full of legacy links that need further processing when they hit the web server. This needs to be handled smoothly.
While I take Greg’s point that the Handle methods were conceived years ago, there’s a real need for them now to work in these newer contexts.
Greg, the docos about session trimeout say the timeout is disabled by default? Can you please confirm timeout behavior if set to zero?
Thanks,
Eric