I’m using the send request method synchronously, getting a string back.
Works great it it’s successful (200 response code). If there is an error (400 or 500), it waits until the timeout is complete to return the result. Why does it do this? and How do I fix it?
Thanks
I’m new here but thought I’d try to solve this with you as a learning lesson. What I determined is you can trap the error code by creating an Event Handler with the Socket. Specifically create the HeadersReceived event or PageReceived event, you can then trap the error codes in the httpStatus value that is passed to this event. However, I’m not having any luck getting those events to fire at all using the synchronous method. But I’m getting a response back immediately on a 404 error in the Action event, it does not wait until timeout, maybe it’s the server not returning a response immediately?
Bad Request (400) and Internal server error (500) are handled by the server before being sent to the client (HTTPSocket). It may not be instantaneous, as it is more complex than a simple 404. Have you tried sending the same request from a browser ? If the browser gets the same delay, then it is the server which waits before replying, not HTTPSocket lag.
Hi Michel-
Thanks for the reply. Yes, I have a REST tool that I tried it with and I get the result instantly when it’s 404 or 200. I also tried playing with the timeout function: when I change it to 15, it takes 15 seconds for a response, when I set it to 5, it takes 5.
Here is my code:
Dim socket1 As New HTTPSocket
Dim dicReturn as New Dictionary
socket1.SetRequestHeader("Session:", app.strCloudSession)
socket1.Yield = True
dicReturn.Value("data") = socket1.SendRequest("GET", url, 10)
dicReturn.Value("status") = socket1.HTTPStatusCode
socket1.Close
return dicReturnMaybe the Xojo class is set to report at the end of timeout when there is an error. Why not set timeout shorter, then ? We are talking about an error code anyway, so waiting longer is not an advantage.
But just a question. Why use
dicReturn.Value("data") = socket1.SendRequest("GET", url, 10)instead of
dicReturn.Value("data") = socket1.Get(url, 10)As I read the LR, SendRequest is precisely for other requests than GET or POST ?
Hi Michel-
Yes, I understand waiting longer is not an advantage, but it will not always be an error code. I could set the timeout to 1 second, but that just doesn’t seem right. Why would the class be set to wait for the full timeout on a error? Is that a bug?
[quote=113394:@Adam Meyer]Hi Michel-
Yes, I understand waiting longer is not an advantage, but it will not always be an error code. I could set the timeout to 1 second, but that just doesn’t seem right. Why would the class be set to wait for the full timeout on a error? Is that a bug?[/quote]
I do not think it is a bug.
When you send a GET request, the HTTPSocket starts waiting for data from the server. You have set it to wait until timeout occur to give up. That’s exactly what it does. There can be many other reasons like network congestion for data not to be complete right away. The socket cannot give you a result before it has completed the task you set for it.
If you want to get the error before, you have the Error event which should fire as soon as the server sends it.
[quote=113394:@Adam Meyer]Hi Michel-
Yes, I understand waiting longer is not an advantage, but it will not always be an error code. I could set the timeout to 1 second, but that just doesn’t seem right. Why would the class be set to wait for the full timeout on a error? Is that a bug?[/quote]
I’ve got a sneaking suspicion that you’re talking to an http 1.1 server which can’t speak 1.0. Try adding a header to your request:
Socket1.SetRequestHeader("Connection","close")This will instruct the server to close the connection when it’s done responding to you.
Greg- That was it! Thank you.
Why doesn’t Xojo support HTTP 1.1? Isn’t that really old?
Its on the list. I’m hoping it’ll get some love as part of the iOS update.
I’m still having some issues with this. I thought adding the Connection Close header fixed the issue, but it didn’t.
It seems GET requests that return a 200 work fine, anything else seems to hang for 7 or 8 seconds. I know it’s not the server, because it works quickly in a REST Test Client.
Is there a fix for this? Is it a bug? I found a few other forum topics that are similar without a real conclusion.
Thanks!
I’m having the same issue as above.
I’m trying to send a PUT request to a Philips Hue Bridge. The JSON content I’m sending gets to the bridge and it works however the http.SendRequest hangs on for 1 second (the currently set timeout). I need it to come back asap as I intend to send this command very frequently. When testing using VisualJSON the request comes back asap so again I know the issue isn’t the server. I’ve also set the Connection header to close. As above when I send a silly command the 200 gets back immediately.
Here’s the code:
[code]Dim postData as String
Dim html as String
Dim url as String = urlField.text
Dim http as new HTTPSocket
url = Replace(url, “%group%”, groupField.text)
postData = “{”“on”": true,"“hue”": %hue%,"“bri”": %bri%,"“sat”": %sat%,"“effect”": ““none””}"
postData = Replace(postData, “%hue%”, str(hueSlider.Value))
postData = Replace(postData, “%bri%”, str(briSlider.Value))
postData = Replace(postData, “%sat%”, str(satSlider.Value))
postLabel.Text = postData
http.SetRequestHeader(“Connection”,“close”)
http.SetRequestContent(postData,“application/json”)
html = http.SendRequest(“PUT”,url,1)
serialReadText.text = html[/code]
Incidently, I get back html from http.SendRequest when it’s a 200 but have very occasionally ever seen the reply when I’m doing the right thing.
Any help?? I’m stuck 
so the Timeout property is actually a connection timeout. Id be curious to know if you set that to 15, does it take the whole 15 seconds to respond?
Yes it does. I get a spinning pizza after 1 second and then 14 more and then the postLabel.Text = postData label gets updated and the UI is responsive again. I find it odd that the postLabel.Text = postData isn’t updated until after the timeout but yet the server most definitely gets the data as soon as http.SendRequest is called…
Something from their api faq Page:
Try without the on property all the time.
Thank you Greg! appreciate your help and speed of replies,
Removing the ON has certainly sped things up a little… It does feel like there’s still something wrong because the VisualJSON app is replying much faster and the iOS app is a lot more resonsive than just 1/second.
Also, if the timeout is set to 10 seconds it’s still locking up for that long. Also with VisualJSON i’m always getting the servers responce as JSON but here I’m still only seeing html get populated sporadically. Again it always comes back when there’s a 200.
Chances are that VisualJSON uses the native sockets and is therefore http/1.1. You should try using the new asynchronous Xojo.Net.HTTPSocket and see if that gets you the rest of the way.
Edit:fixed the link