HTTP Request issue

Troubleshooting
1

Somehow I cannot get a HTTP Request complete.

I’m running a state machine in loop, a state transition requires the loop to restart with a 1 ms delay.
State 1: Connect to 192.168.1.100*:80 (success)
State 2: Send HTTP Request (success)
State 3: Receive webpage (failure)
Responce should be, according to pc terminalHTTP/1.1 200 OK<\r><\n> Date: Tue, 28 Jan 2014 20:31:10 GMT<\r><\n> Server: Apache<\r><\n> Vary: Accept-Encoding<\r><\n> Content-Length: 11<\r><\n> Connection: close<\r><\n> Content-Type: text/html<\r><\n> <\r><\n> < 1234;12 ><\r><\n>
Resonse Spark Core reads is:

HTTP/1.1 200 OK<\r><\n> Date: Tue, 28 Jan 2014 20:34:24 GMT<\r><\n> Server: Apache<\r><\n> Vary: Accept-En
It just ends after about 80-100 chars, my code keeps reading, but nothing is coming.

Strange part is, the google example does work, but only occasionally.

Code

The most annoying part is that a faulty request, something like GET /blard HTTP/1.0\r\n\r\n, receives an 404 which is read completely and displayed on terminal and state 5 (parsing data)

*Example on my website

2

Hi @Jeroen3, this is something I encounted yesterday as well… and the solution is here…
https://github.com/spark/core-firmware/pull/67

If you build your code locally you can just replace those two edited files and it should work.

I don’t think it’s the complete fix, but it gets us downloading all of the data :smile:

3

Why does’t that bug change a 404 response, while affecting a 200 response massively?

Edit:
Because a 404 is about 965 bytes long and a 200 response is only 170 bytes.
I added 64 dots to the end of the page and now it works!

There must be an issue in the used circular buffer. (Probably not using this one :wink:)

4

I don’t think that’s the answer… because I have been experimenting with 200 responses that return variable amounts of data anywhere from a couple hundred bytes to 1500 bytes. It’s some issue with how the data is buffered from the CC3000 and how the TCP library extracts it. You could be right about a bad circular buffer though :wink:

5

I guess the stack hash issues, just now it bricked itself again.

6

I had better luck with a minor code change I explained in a post over here:

Hope it works for you!

7

I’ve just discovered that the succes rate of a TCP conversation depends on the size of the packet sent back and the time delays between TCP lib calls.