some very strange numbers from getLastReturnCode()

[interactive-matter]

Also, I seem to be getting some very strange numbers from getLastReturnCode(). The debugging prints show status 200, but getLastReturnCode is giving me varying numbers, even negative numbers:
1300
513
2
512
-236
1024
etc.. There seems to be no fixed pattern

[interactive-matter]

this looks like a rather nasyt memory problem … will look into it (promised)

[bilics]

Hi there,

I am facing the same problem here (Arduino Mega 2560).

Any updates on this issue ?

Thanks in advance,

[Apollon77]

Same here, only in rare cases

[Apollon77]

When I look at the code I don't know if the variable reference to the instance-variable is correct and the best way here:

fscanf_P(stream, PSTR("HTTP/1.1 %i"), &lastReturnCode);

maybe better to use a local variable to write it and copy that to the class member later on ?!

I will change that locally and test it for some days.

[Apollon77]

I discovered one thing: The code (especially with this fscanf) assumes that there is content to read. When there is no/not enough content to read then fscanf returns with EOF or 0 - return value of fscanf is normally the number of matched items (%i) or EOF on error.
When we assume there is no data then I don't know (didn't find anything so far) what really happens to the variable that should be set with the value. Don't know if thepointer is used somehow and that's why there are stupid values in there?!
I added some error-checking in my local code and will try it the next days.

[Apollon77]

As an update: I've seen in my code that any time the fscanf_P was not able to match successfully the details are the same:

• content available was "HTT"
• ferror() returned "16" or the stream. feof() returned false
• The read after it worked

I will add debug output of "errno", but at least this is not set in HTTPClient class ... I will also try to make an available-loop till at least x characters are available before starting to read ... Will update here ...

[Apollon77]

Next update:

• errno does not have any value, so it brings not more infos.
• I changed the code so that the first line is read in total and then the matching is done by sscanf ... so I have seen that it seems that mostly when the problem occurs only the irst 5 characters where read and the last was wrong ...

After many tries I assumed a timing issue with receiving the data from remote ... so I tried to add a "delay(100)" to simply give it more time to receive the data (not ideal, but a first try) and hey ... no more problems since two days ...
I will now try to make the loop a bit better by using the client below the stream and available() till 10 chars or 100ms are away ...

[Apollon77]

So, after a month of having it working without problems ... I removed all debugging stuff and committet it.

See pull request #15 or my fork at https://github.com/Apollon77/HTTPClient

[Apollon77]

With merging my pull request this issue hopefully can be closed