HandleURL Web 2.0 Return False not triggering session

Targets Web
1

I have some code that stopped working in the past few releases.

let’s say I send a link to a user: mysite.com/jUhYgT

I used to be able to return false in the HandleURL function and it would pass the torch to Session.Opening

This is no longer working, any ideas?

Thanks

3

It would be helpful to see the code you have in HandleURL.

4

This actually seems to now be working as per the documentation. If you return True, you should be building a response to send, otherwise you are served a 404 when you return false and have something in Request.Path. It would be nice to be able to ignore the path and serve a WebSession, though.

Here is my test code, with a break in Session.Opening:

Function HandleURL(Request As WebRequest, Response As WebResponse) Handles HandleURL as Boolean
  if Request.Path.Length > 0 then
    System.DebugLog( "Found path" )
    Return False
  else
    System.DebugLog( "No path" )
  end if
End Function

Note that, regardless of the Return value in the first condition, a 404 is always served and Session.Opening never occurs if there is data in Request.Path.

Tested URL:
http://127.0.0.1:8080/eriuhoieu

5

To get around this, I’d probably switch from using a path to query string, IE:
http://127.0.0.1:8080/?a=1&b=2

Using this method you are better able to control what your user experiences. For instance, I just wrote up this bit to return the Hello World example in the documentation if the value of the “a” parameter is 1, otherwise the app will continue creating a normal WebSession.

if request.Parameter( "a" ) = "1" then
  Response.Write("<html><body>Hello World!</body></html>")
  Response.Status = 200 // An HTTP Response code of 200 means everything is OK
  Return True
elseif Request.Parameter( "a" ) = "2" then
  '// Set some data, do something else, whatever you need
  '   but still get a regular WebSession
end if

'// If none of the above conditions are met, continue to a normal WebSession.

EDIT: I always forget about Request.Parameter.

Hope that helps!

6

It was my fault. I should have prefixed with a hashtag (EG: mydomain.xyz/#1234). When you do that HandleURL returning false hands off to session.open

Thanks everyone for your input. Sorry for my bonehead mistake.

1 Like
7

Thanks for reporting back with the solution!

8

I don’t get how Xojo works. I miss this kind of construction:

Function HandleURL(Request As WebRequest, Response As WebResponse) Handles HandleURL as Boolean
  Var sess As Session = RetrieveCurrentSessionOrCreateANewSessionIfNone()
  Var someData As String = DoWhateverYouWant(Request, Response)
  sess.storethisproperty = someData // You can retrieve this value again anywhere during this session
  Return True // Because Xojo wants it
End Function

[/quote]

1 Like
9

In this case, the processing was happening in an App-level event, before a Session exists, so you can’t access the Session to do anything.

10

So I created one.

1 Like
11

Right, but there could also be caveats that we don’t understand when it comes to Session construction in this manner that @Greg_O_Lone could share. Sessions are a bit mystifying because of their threaded nature, and I’d imagine it’s a delicate balance as is.

As I said earlier in this topic, I’d like to be able to handle paths without blocking Session creation, and I’d also like to control a bit more of the Session from app-level events as you propose.

12

I see people creating all sorts of workarounds with roundtrips passing data with overheads to client and back trying to trigger a session creation and storing values. That’s insane.

1 Like
13

I agree, it’s not very intuitive. If Sessions were more persistent then we could easily iterate over App.Sessions and change values and call methods, but there are a few Feedback Cases for things like this already, IIRC. I can only assume that its complexity is such that other, more pressing functionality issues have to come first.

14

From what I can see, a Websession gets started when Handle URL exits, so there’s no communication between HandleURL and the session except URLparameters.

It would be nice if the incoming URL & URLparameters could be changed by HandleURL so that a session could be started, also having the benefit of some preprocessing. At the moment you have to do a browser redirect for this: Processing post requests to populate a web page impossible? - #5 by Eric_Wilson

1 Like
15

If you need to change the url, you could use an http redirect.

Response.Header("Location") = "url with new parameters"
Response.StatusCode = 302 // temporary redirect
Return True
16

The purpose of changing the URL would be to strip the path so that the browser starts a session in reply. But better if we could do it with the original request because different UAs treat 302s in different ways. For example, some accept relative references while others do not, while others won’t obey redirects.

It would also be nice if there was a loop back into the request queue rather than going out to the network with localhost btw.

17

You should never use relative anyway. IIRC the spec says to always use absolute urls. If a client doesn’t natively support redirects, they’re easy enough to implement yourself.

I’m having trouble understanding this request. What does “rather than going out to the network with localhost btw” mean?

18

So just to be clear here… any url that doesn’t conform to the URIs supported by the framework will always return a 404 NOT FOUND response if you don’t handle them and return true. The only URL that should spin up a new session is an empty one, and that is by design.

Until recently there was a bug which sometimes caused sessions to be spun up for every incoming request which was not already associated with a session… regardless of whether you returned true or false, and yes, it existed in the old framework too.

1 Like
19

In a complex server environment the web service doesn’t necessarily know the URL of the incoming request, so relative references are sometimes all there is to use absent a way of passing through HandleURL to a session. Implementing a callback by sending JavaScript is also not always possible such as when using another Web service or a more secure browser.

20

I will get back to you on the loop back and what it would be useful for. I need to make sure first I’m not causing memory leaks.

21

Sure you do. Just look at the Host header.