In my opinion only hobbyists will refactor.
I don’t see the point to check my libraries for broken functionality every time there is a new version of Xojo.
For instance Web controls positioning regression introduced in 2025 still exists in 2026R1.1
Now WebSessionContext…
And I’m experiencing this exact pain in various of my projects.
I occasionally make some changes, compile and deploy. Weeks later, I eventually use one or another subdomain in my website for a specific task and it just doesn’t work anymore. Then I remember about this change and I need to refactor HandleURL (and re-deploy); terrible when what I want to do is urgent.
Hi all,
Coming from the “When to spin up a Session?” thread — wanted to add some production context here where the root cause was first identified.
The performance numbers Erik shared tell the real story: the 55% throughput drop from 2025r3.1 to 2026r1.1 isn’t just a benchmark curiosity — it’s the visible symptom of a fundamental architectural shift. Spinning up a WebSession for every HandleURL request conflates two completely different use cases that need to stay separate.
In my production app (DocsTool — multi-user document management), the entire backend is a single comm_api HandleURL endpoint with 89 session-aware call sites. The dispatch point looks like this:
// App.HandleURL — single entry point for all authenticated API calls
If request.Path = “comm_api” Then
Var json As New JSONItem(request.Body)
Var instanceKey As String = json.Lookup(“instanceKey”, “”).StringValue
// This is the line that breaks in 2026r1.1:
Var context As New WebSessionContext(instanceKey)
If context.Session = Nil Then
response.Write(“{”“error”“: ““Invalid session””}”)
Return True
End If
// Dispatch to ~89 handlers across 15 modules
Select Case methodName
Case “loadCommunications” : Return Mod_HandleURL_Communications.Method_loadCommunications(…)
Case “saveTicket” : Return Mod_HandleURL_Tickets.Method_saveTicket(…)
Case “loadAttachment” : Return Mod_HandleURL_Attachments.Method_loadAttachment(…)
// … 86 more
End Select
End If
Every authenticated action — file handling, real-time UI updates, multi-user session management — routes through this single dispatch point. On 2026r1.1, the app is completely non-functional from line 1.
The pattern works precisely because HandleURL can be either sessionless (public/API requests) or session-aware (authenticated UI callbacks) depending on what the request needs — not because the framework decides for you.
For the sessionless side, the same HandleURL also serves pure HTTP endpoints with zero session overhead:
// These run fine sessionless — no WebSessionContext needed:
If request.Path.BeginsWith(“att_download/”) Then
Return Mod_HandleURL_Attachments.Method_HandleAttDownload(request, response)
End If
If request.Path = “dq_ping” Then
response.Status = 204
Return True
End If
Both patterns live in the same HandleURL handler. They need to coexist.
Ricardo, the fix I’d advocate for is an explicit opt-in model:
- HandleURL runs sessionless by default (restoring 2025r3.1 performance)
- WebPage.Show from HandleURL remains possible but requires the developer to explicitly opt in — perhaps via a new method or a property on the request
- New WebSessionContext(key) continues to work when called from a genuinely sessionless HandleURL context
A backward-compatible guard that already works today and could serve as a migration path:
// Guard pattern — safe in both 2025 and (hopefully) 2026r2:
If Session Is Nil Then
Var context As New WebSessionContext(instanceKey)
// … session-aware code
End If
This preserves the SEO/performance use case, the CodeInjector pattern, the comm_api pattern, and the new WebPage.Show capability — without forcing any of them to compromise the others.
The 10k req/s numbers from 2026r2 internal are very encouraging. Looking forward to seeing how the final design lands.
Roberto
2 Likes