I’m new to XOJO, doing my first steps, and I got a bit confused by URLConnection’s cookie behaviour, and I wonder if this is somewhat intentional and its reason is just not obvious to me, or if it’s actually a bug.
con= New URLConnection
foo= con.SendSync("GET", someUrl)
bar= con.SendSync("GET", someOtherUrl)
The server of someUrl ist the same as of someOtherUrl. The response of line 2 contains a cookie sent by the server of someUrl.
On macOS the request of line 3 sends the cookie, which was received in line 2’s response.
On Windows the same request does NOT contain that cookie.
How can I achieve the behaviour as seen on macOS also to happen on Windows? I know that I could set the cookie(s) explicitly, but for that I would have to even know its content (but I found no way to read it from the response headers of the request in line 2). But even if I would know the cookie(s) set in line 2, it would be far more convenient if I wouldn’t have to deal with it myself but could just let the URLConnection handle it the same way as it happens on macOS.
There’s a cookie bug with WebResponse ( see <https://xojo.com/issue/66772> ) no idea if that code is shared with URLConnection (I would guess not, but…?)
I’m trying to create a Desktop application, and if(!?) I got it right, WebCookieManager is not available for those, but only for web applications.
I was able to solve it by manually reading and storing the cookies each time (which sadly also required to use HTTPSecureSocket instead of URLConnection). It works, but it’s a huge (and even deprecated) mess.
As with William’s WebCookieManager recommendation it seems to be the same for WebResponse - to be not available within Desktop applications (I’m not fully convinced I got this right though!?)
But I found some (bad but) working solution using HTTPSecureSocket and handling cookies myself.
Originally I thought to have one URLConnection and the server my application connects to, might set some times cookies, which would be used in all future re-uses of the one URLConnection.
And this works just fine the way as I imagined it - but only on macOS. On Windows it’s actually extremely weird (or very different to what I would have expected). The server uses a lot of redirects (302) in its responses. URLConnection follows those redirects and keeps/uses the cookies during the redirects (as in first response sets cookie and redirects, resulting in a second request which contains the just received cookie). But if I later reuse this URLConnection (as in calling .Send or .SendSync) all cookies that have been set so far are forgotten.
Because of the redirects I can’t use .ResponseHeaders to read the cookie manually either (as I am only able to read the “final” ResponseHeaders after all redirects have been followed).
But it works by doing a connection.SetRequestHeader("Cookie", connection.PageHeaders.Value("Set-Cookie")) (with connection being a HTTPSecureSocket). It feels like a very dirty hack, but it works, and till I find a better replacement I will just stick with it. Or maybe I will write class/module which handles it in a safer and better way than this quick and dirty approach does, once (and if) I get more familiar with Xojo.
And in case that anyone else has the same problem and sees this - if you want to do the same, be aware, that this works only if there is only one cookie possible (if there is more than one cookie, it won’t keep all of them).
Also somewhat unexpected: at least on Mac, the app ignores the system-wide proxy settings.
I’ve got it working, even though I’m not happy with the solution. But there is no need to look any further into it, as I’ve decided to go with a different framework/IDE.
I don’t mean to resurrect a super old thread, but I recently ran into this issue in one of my own projects and can confirm that it’s still happening. I’ve filed a ticket here:
But that’s exactly what uou’ve done, @Patrick_Salo . That’s the third or so time in recent days that I’ve found myself reading a years old thread only to discover (because the date stamps on threads are so faint) that it is old.
Please would folks make a new thread with a similar name and just reference the old one? Thanks.
Yes, that’s exactly what I did and on purpose. Discourse supports locking of old threads after a set period of time and because this is not turned on, I replied.
If the Xojo team or the consensus is for no replies to old threads, then the UI and administrative rules should be setup to point folks in the preferred direction, especially as every forum/Discourse instance out on the 'Net might have it’s own rules or traditions.
Can’t really help you there. Have you tried using high contrast mode in your OS or browser settings? Or maybe dark mode or light mode depending upon what you’re using? Maybe reach out to the Xojo folks or even Discourse to see if they can adjust the colors as this sounds like an accessibility issue. Personally I don’t have any issues seeing the dates on the threads in dark mode on macOS & iOS.
Maybe I’m missing something here, but just because a thread has a Solution, the thread can still be replied to. Discourse doesn’t support this automatically, but if the preferred workflow is zero replies, then maybe you can suggest to the Xojo team to manually lock all threads once they’re marked with a Solution.
I never said I wanted to nor do I intend to remove the solution.
Why should I care about having control to remove the solution? I’m not really following…
This is specifically why I replied to the thread. If you read the entire thing at a macro level this has taken place…
OP had an issue
OP created a workaround and marked it as the Solution
The actual issue from #1 remains
The proposed solution is really just a workaround - even the original poster describes it as a “very dirty hack.” Maybe I’m in the minority, but if I came across this thread while troubleshooting the same issue (which appears to stem from a deeper Xojo framework problem), I’d genuinely appreciate a follow-up pointing to new developments, the related Feedback case, and - ideally - the eventual fix. It helps turn a dead-end into a more useful resource for others down the line.
It might just be personal preference, but when a thread starts a story, I prefer to see the conclusion in the same place - rather than having it scattered across multiple threads. That said, I realize not everyone feels the same way.
If the so-called solution is really just a workaround - and even described as a “very dirty hack” - and the root cause appears to be a Xojo framework issue, then relying on it in production seems riskier than addressing the underlying problem directly. Long-term stability comes from fixing it at the source.
In all honesty, I originally posted to help others who might run into the same issue. I wasn’t expecting pushback for trying to contribute.
Based on some of the replies, it sounds like I might be out of step with the norms here. Could someone kindly point me to the guidelines or expectations that everyone’s following?
And if there’s a strong consensus against replying to older threads or those marked as solved, maybe it’s worth asking @Alyssa_Foley or the Xojo team to adjust the Discourse settings for the forum.