Xojo.Net.HTTPSocket cannot communicate through proxy server, correct?

hi all,

just before i switch back to the classic framework, i wanted to be sure that there really isn’t a way to make the Xojo.Net.HTTPSocket talk through a proxy server.
i’m creating a API tester app, to validate the new API’s my LMS vendor is building for us, but can’t seem to get anything when i’m at the office, while at home it works fine.
Must be related to the Proxy server which is needed when at the office.

thanks,
Kristof G.

Actually it can, it uses the system proxy settings.

Thanks Greg.
The PageReceived event doesn’t seem to get fired though, even after waiting several minutes. Our company uses a proxy script by default, but i could set it to a fixed server:port setting and see if that has any effect. will report back.

So, at the office where proxy is necessary to get outside, it’s not working with fixed proxy server nor with proxy script.
i just drove home, ran the exact same code from the same pc but now on my home network (both with and without VPN running) and it works fine.
Any ideas how to troubleshoot a problem like this? how can i see what the socket is doing, some verbose information available?
thanks
Kristof

by the way the API uses an SSL connection, and authentication is embedded in the RequestHeaders.
and port 443 is definitely open on our company firewall.

Which platform are you running at work?

Windows 7 Enterpise - SP1, 64bit, and i’m using Xojo 2016 Release 2.

Does the current version of our Feedback app work on your computer at work?

Is it a Web app running on Windows? If so, I ran into the exact same problem where the PageReceived event would not fire in an app I made this week. The GlueKit httpsocket solved the problem for me.
The code worked fine in a windows desktop app but not in a web app until I just substituted the GlueKit socket.

Are you subclassing Xojo.Net.HTTPSocket? This could be related then feedback://showreport?report_id=42596
This is the major show-stopper for us with the new framework since we cannot replace the old class without heavy rewriting of the communications logic.

it is actually a Windows desktop app, and was indeed subclassing Xojo.Net.HTTPSocket, like in one of the examples (adding some methods on the class definition, then dropping the class on the windows to get an instance as a control and adding the Event Handlers there. No luck. I haven’t read the feedback case yet, but will do next.
In the meantime i did rewrite to use the Classic framework again, but with the classic I have the issue that using the Subclass-drop-on-window-to-create-control routine gives me strange behavior: it only works once, the second and all consecutive times i get a 400 error (bad request). must have something to do with secure=true.
To make it work i had to define everything in the class, event handlers and all. it works but it doesn’t feel right (the class doesn’t know anything about the control i have on the window, so now it’s hard coded, which is the opposite of encapsulation)
The alternative is of course to define everything in code, but that is outside of my skill set at the moment.
I was hoping my API tester app would turn into a business app we could use to speed up some of the master data entry we need to do, so i’m still hoping to find a better way to program this.
thanks,
Kristof

Sorry Greg, missed your Feedback app comment: i actually never installed the feedback op my work pc, but I did that just now. And no it is not able to connect.
The message reads:
“The Xojo Feedback server could not be reached.
Feedback requires the ability to communicate with the Xojo server in order to operate. Please try again in a few minutes.”
cheers,
Kristof

To revive this thread - aside from the bug reported with subclassing and threads, is it true that the new Xojo.Net.HTTPSocket will automatically handle proxy settings? Therefore, we just remove Proxy support from our apps when upgrading and it should “just work”?

Yes!

Well, to supplement, it uses the system proxy settings. So users may ask you how to do it, so you’ll have to point them at the system level setting.

For now I d’ont know to to set the system proxy settings (ubuntu) in order to make Xojo.Net.HTTPSocket work with it…

I tried to set all the environment variables (http_proxy, https_proxy, HTTP_PROXY, …) and also with the desktop settings (gsettings org.gnome.system.proxy…) but I always get a “Cannot connect do destination” error (code 4)

Any clue ?

[quote=373995:@Martinho Dos Santos]For now I d’ont know to to set the system proxy settings (ubuntu) in order to make Xojo.Net.HTTPSocket work with it…

I tried to set all the environment variables (http_proxy, https_proxy, HTTP_PROXY, …) and also with the desktop settings (gsettings org.gnome.system.proxy…) but I always get a “Cannot connect do destination” error (code 4)

Any clue ?[/quote]
You must use the system settings with the new socket. There’s no way to do it otherwise.

They’re in the Network Settings.

Well but how to configure it with the command line on a faceless server (VPS) ?

All I did was a quick internet search for “Ubuntu proxy settings” and there were several articles on how to set that up.

Yes I did too. And, as I said, I think I tried them all. The proxy settings are fine for all the other applications but Xojo.Net.HTTPSocket doesn’t seem to handle them. Or it is something else but I don’t know what.

Perhaps lib soup was not the best choice : https://curl.haxx.se/libcurl/libsoup.html

At the end, I think that am will have to go back to the old framework which handles proxy settings. But its HTTPSoket is not as “modern” as the new one. None is the perfect choice for now.

Forum for Xojo Programming Language and IDE. Copyright © 2021 Xojo, Inc.