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.