Is there anyway to capture that a xojo.Net.HTTPSocket has followed a redirect?
In other words when I do a .Send() is there an event that tiggers when the 301 or 302 response happens.
It doesn’t look like it to me but I just wanted to make sure I wasn’t missing anything.
Interesting question. Does HeadersReceived occur more than one time, perhaps with the redirect status the first time?
No, tried that as well. Seem to only get a headers received for certain “final” status codes.
I’m pretty sure I can’t detect them using xojo.Net.HTTPSocket but I just wanted to make 100% sure on the forum since this is the first time I was exploring the new framework for the HTTPSocket.
You receive a 301 or 302 code and the html holds the new address (URL) to use ?
When you receive a 301 or 302 one of the response headers is “Location” and that holds the URL you would jump to. I have a need to see that URL before it is retrieved as a next step.
I’ve been exploring the new class for 15 minutes or so and I see that xojo.Net.HTTPSocket is very limited in comparison to the classic HTTPSocket.
It obviously has some improvements in terms of the basics but it lost a lot of functionality for those who like/need to look “under the hood”.
This can happens, but you may discover (sometimes) that you have a lot more code to get what is missing.
Stupid question: do you have a good reason to not use the version from the Classic Framework ?
I can use the classic version. But wanted to start using the version that supports HTTP 1.1 and also handles secure connections transparently.
I also assumed that xojo.net.httpsocket would be the one that gets any future attention and that classic could/would be depreciated at some point soon.
Did you read the news from the last XDC Conference (or so) about the future of the Classic / New Framework ?
The future is unknow (yes, I read Could / Would deprecated).
In the mean time, I do not know what the good advice can be: use Classic Or New Framework. Personnaly, I stay with the Classic framework until further notice from Xojo…
Good reading here: XDC Keynote Recap .
Either way, you are certain to have the current functionality available for a few years:
1- the 2.0 API is somewhere in the future;
2- It will probably be introduced as beta, much like 64-bit was;
3- Xojo has been very good with deprecations and feature removals, in the sense that before something is removed, it is deprecated but available for several years.
I would say that it is quite safe developing something with features available now. By the time the feature is due to be removed, you will surely be ready for an upgrade or a new and improved release of your software. Or perhaps even retired…
I use what works best in the current arsenal for my intended use without even worrying a tiny bit. When the time comes that 2.0 API is available, there will still be a few years to plan a migration. Case in point: the classic framework vs the new framework. We can still use classic even though new has been there for a while already.
Bottom line: Use the best tool for the job available now and don’t worry about it.
Xojo.net.httpsocket should handle those redirects for you.
[quote=410277:@Greg O’Lone]
Xojo.net.httpsocket should handle those redirects for you.[/quote]
His point is that he does not want the socket to handle it for him. He wants to see what they are before going there:
The preference would be for httpsocket to handle the redirects but allow me, via an event, to see the redirect and then allow me to stop it or allow it.
The huge failing of the new httpsocket is not allowing me to see the response headers in total.
In order to see a response header you have to know what you are looking for. At least as far as I can tell.
Id really like to know the reasoning though. In my experience, you request a URL and you want the socket to go and get the content for you.
I would use a TCP Socket if I wanted to look under the hood.
First theoretical - You want to create a debugger type app. In the app you type in a URL and you see the process. Header requests and responses along with all the codes. Similar to what you see in the Dev Tools of a browser like Safari or Chrome.
And the practical need that I have - I make a call to an API. In this specific case the API doesn’t return a JSON or some other data it first responds with a 302 - Moved. The URL of the move contains within it the data I need but the actual data returned from following the URL is useless to me. So, for efficiency I would normally do a “HEAD” call to the API URL then examine the “Location” header response for the URL of the 302 that is returned. Then I would not actually call the next URL.
And it is true all of this can be done with a TCPSocket but then you have to craft the entire request and write code to parse the return.
It’s really not a big deal and there are plenty of work arounds I was just starting to look at the new httpsocket and went into it thinking I would see similar functionality of the classic httpsocket. And much of that functionality isn’t there although it did add some other attractive features.
The underlying OS API’s in use for Xojo.Net.HTTPSocket do not provide us with this data.
[quote=410426:@Jason Parsley]
The underlying OS API’s in use for Xojo.Net.HTTPSocket do not provide us with this data.[/quote]
Any chance you’ll be using something different cough curl cough under the hood for whatever replaces xojo.net.httpsocket?
Not sure 
There are other OS built in apis that do provide this. We just happen to be using one that doesnt at this time.