I am trying to use the HTTPSocket class. Using Send(method As Text, URL As Text) I get successful responses in a PageReceived event.
However, if I want to initiate a second request within the event function PageReceived things seem to become somewhat unpredictable…
On the Mac it seem to work ok after I closed the socket first, but on the RaspberryPI it results in a segmentation fault.
When I initiate the follow-on request outside the PageReceived event it works fine…
How does one deal with multiple sends when conversing with a web service?
Ok, so you confirm that initiating a new request within an HTTPSocket generated event is a no-no…
That is not very elegant…
I can understand that this would be the case for progress events, but for events like PageReceived which is an event that basically completes the request, it does not seem logical…
OSX generates an exception, which is ok, but Linux ARM goes down in flames with a segmentation fault…
Actually, when I close the socket at the end of the PageReceived event function and raise a new event which basically delivers the parsed data to the requestor it works fine on OSX… The requestor initiates a new request to the static socket instance within its the dataIsReady function…
No succes on Linux ARM though… So I will look into decoupling more or creating new HTTPSocket instance for each request…
The last statements in the PageReceived function:
me.Disconnect
if valid then
RaiseEvent dataIsReady(dict)
end
The fact that it appears to work on OSX doesn’t mean that it is the right thing to do. You are interrupting the normal processing of the socket. I would imagine the internal processing looks something like
' do some stuff
' call PageReceived
' clean up and close the socket
My guess is the socket just isn’t “done” during page received. This is one of many instances where you need to push the next process outside the current event sequence so the framework has a chance to complete what it is currently doing. That’s what the Timer is for.