Trouble with webserver requests freezing
amereservant opened this issue · 6 comments
I would like to first thank you for this excellent and well-written library!
I am having a bit of trouble with the HTTP_Server example. When I connect to the Arduino via Chrome or Firefox, it will display the page contents, however it continues to load and never completes. Even after well over 30 seconds, the page continues loading, yet never finishing.
In spite of being a web developer, I cannot seem to figure out what's lacking nor why the request is being held open. I cannot see the response data either, because any HTTP Request viewers I try never report since the request will not finish.
Your code is cryptic enough to where I can't quite determine the process, so I was hoping you might be able to offer some insight into this. I really like the fact your code is very lightweight, yet robust. Thank you.
Hmm. I can't think off the top of my head why that would be.
From memory, I don't think I made it send a Content-Length header, maybe
your http clients are getting stuck because of that, if one was going to
add a Content-Length header for html or text output types, then you
would do that in the section around lines 428 to 446 of
ESP8266_SImple.cpp which builds the headers to be printed. You'd
probably just use the strlen of "dataBuffer" as the content length.
You could also try turning on debugging in the library, comment out the
#define ESP82336_DEBUG(...)
#define ESP82336_DEBUGLN(...)
in the ESP8266_Simple.h file (lines 46 and 47) and it will spit out more
information to your serial terminal.
On 2015-05-12 18:38, David Miles wrote:
I would like to first thank you for this excellent and well-written library!
I am having a bit of trouble with the HTTP_Server example. When I connect to the Arduino via Chrome or Firefox, it will display the page contents, however it continues to load and never completes. Even after well over 30 seconds, the page continues loading, yet never finishing.
In spite of being a web developer, I cannot seem to figure out what's lacking nor why the request is being held open. I cannot see the response data either, because any HTTP Request viewers I try never report since the request will not finish.
Your code is cryptic enough to where I can't quite determine the process, so I was hoping you might be able to offer some insight into this. I really like the fact your code is very lightweight, yet robust. Thank you.Reply to this email directly or view it on GitHub [1].
Links:
[1] #2
I appreciate your quick response. I cannot grasp what you're doing in the code, so I am unable to try adding the Content-length header. I don't know C++ and can do fine with typical Arduino coding, but you appear to be using more advanced memory allocation and string formatting that is beyond my comprehension.
I did turn on debugging as you suggested and here's what it spits out when I visit the millis page:
( Now you can use your web browser to hit the IP address above. )
Packet Length: 372
OVERFLOW
OVERFLOW
OVERFLOW
OVERFLOW
OVERFLOW
SEND {{{AT+CIPSEND=0,94}}}
SEND {{{AT+CIPCLOSE=0}}}
busy inet...
after a minute or so, it finishes with this:
Packet Length: 317
SEND {{{AT+CIPSEND=1,143}}}
SEND {{{AT+CIPCLOSE=1}}}
busy inet...
From what I've read regarding the "busy inet", it seems that might have something to do with it, but I'm very limited in my understanding of this.
Actually, I think you may be right on the Content-length part. It seems to time out after 3 minutes or so and that might be because it waits to see if there's any more content or not since it doesn't know how much to expect.
I'll do some more research and see if I can figure it out and if not, I'll try implementing an easier solution for handling the requests. I'm not sure I can modify this code enough for the project I'm trying to build, so a more basic code might have to do until I can find the time to learn more C++. Thanks again.
Sometimes memset and strncpy_P don't work fine.
Only change line 465 of ESP826_ Simple.cpp for that:
if((responseCode = this->sendCommand("AT+CIPCLOSE=0\r\n")) != ESP8266_OK)
I can confirm that adding the Content-Length header is what solves this. Be sure to increase the header buffer from 45 to 64 to accommodate the addition of the new header.
Content-Length header has been added today (support for 0.9.5.x firmware has also been added today.)