I’ve filed a bug report about this with a sample project (#26630), but perhaps I’m simply unaware of a change in Xojo that I can workaround. I have an HTTPSocket that, when it receives a 302 redirect HTTPStatus in the HeadersReceived event, sets the cookie in the request header and does a “get” again with the new address. For the web site I’m dealing with, this generates a second 302 HTTPStatus event, and after redirecting that I finally get an HTTPStatus of 200. However, after that the PageReceived event never fires, so I never get the contents. This worked in all RS versions through RS2011R4.3, but not in Xojo.
Are you resetting the socket before issuing a new GET/POST?
No. I’m replacing any cookie info in the header, and changing the URL of course, everything else, such as the query, is left alone (and is correct). As I said, I get a valid reply with the HTTPStatus of 200, but the PageReceived event doesn’t fire. BTW, the SendProgress event fires repeatedly (and oddly, in that it will contain the same bytes several times in a row), and I can see the reply is correct. Just no PageReceived.
Brad’s right. You need to reset the socket. This is a change that was made in 2012r1.
Aha. Sorry to be dense, but exactly what does that mean, and how do I do it? Simply iterate through the request headers and reset them to what they already are? Or something else? Thanks.
dim sock as new HTTPSocket
It’s actually a HTTPSocket instantiated in the IDE (not dimmed). Can I just save the headers, then do a
me.ClearRequestHeaders
and restore them, or do I need to actually make this socket a class, instantiate it again, and fill in the request headers?
You can try it, but I’m not certain that the socket will be completely reset.
Jonathan,
In my experience, ClearRequestHeaders does the trick. You would then restore them before calling Get or Post. This works well for me for a socket embedded on a window.
-Brad
Thanks Brad and Greg for all the help.
I’ve spent a fair amount of time on this and thought I’d pass on what I’ve learned. With a little more information from Brad, I moved all the code from the HeadersReceived event to the PageReceived event. When I get a redirect (HTTPStatus of 301 or 302) I do not have to reset the socket, I use the same socket to GET/POST the new URL. And in the end, the PageReceived event will get the correct final content (HTTPStatus of 200). So whatever was causing the problem was that redirecting from the HeadersReceived event using the same socket instance was for some reason prevent the socket from receiving the final PageReceived event. My bug report and example project is still filed in case this is not the expected behavior.
I’d guess it’s “expected behavior” unless you explicitly close/disconnect the socket in HeadersReceived, since the HTTPSocket is presumably still open and receiving content when HeadersReceived is raised. At any rate, a redirect shouldn’t have a lot of content sent with it, so moving to PageReceived shouldn’t add much overhead.