Hi Nils,

I might be wrong, but when I looked at this statement if (aRequest.hostname != NULL) in the implementation of HttpClient::request() I thought that some users might initialize the hostname field of the request this way myRequest.hostname = ""; and will assume that the request will be going against the given ip, but the above if-condition might be evaluatec TRUE and hence the request will not go against the ip but against an invalid hostname.
But I'm not too sure after having a second look at the implementation of the String class, so I might well be mistaken.

Cheers

Andy

Veryfing code using this library in Particle Build fails with this error:

HttpClient/HttpClient.cpp:231:22: error: 'delay' was not declared in this scope
             delay(200)

In HttpClient.h, the value of buffer is only 1024. This is pretty small and means that URL's longer than a few hundred characters are truncated. I'd love to see this number increased to say, 8192. Or expose it so the user can select a value that meets their needs.

when i use a buffer that is too small, i have problems on the next request. changed my buffer to 1024, but then it might have trouble later with memory...

if the buffer is full, maybe you have to read (and truncate) all the response anyway.

I am trying to use application.cpp and supporting files. I get a long list of compile errors below and can't read through them. Has anyone seen this?

In file included from ../inc/spark_wiring.h:29:0,
from ../inc/spark_wiring_stream.h:36,
from ../inc/spark_wiring_client.h:24,
from ../inc/spark_wiring_tcpclient.h:29,
from HttpClient.h:5,
from HttpClient.cpp:1:
../../core-common-lib/SPARK_Firmware_Driver/inc/config.h:12:2: warning: #warning "Defaulting to Release Build" [-Wcpp]

warning "Defaulting to Release Build"

^
In file included from ../../core-common-lib/CC3000_Host_Driver/evnt_handler.h:38:0,
from ../inc/spark_wlan.h:33,
from ../inc/main.h:38,
from ../inc/spark_utilities.h:30,
from ../inc/spark_wiring.h:33,
from ../inc/spark_wiring_stream.h:36,
from ../inc/spark_wiring_client.h:24,
from ../inc/spark_wiring_tcpclient.h:29,
from HttpClient.h:5,
from HttpClient.cpp:1:
../../core-common-lib/CC3000_Host_Driver/socket.h:146:0: warning: "fd_set" redefined [enabled by default]

define fd_set _types_fd_set_cc3000

^
In file included from /opt/gcc_arm/arm-none-eabi/include/stdio.h:47:0,
from ../inc/spark_wiring_print.h:30,
from ../inc/spark_wiring_string.h:33,
from HttpClient.h:4,
from HttpClient.cpp:1:
/opt/gcc_arm/arm-none-eabi/include/sys/types.h:256:0: note: this is the location of the previous definition

define fd_set _types_fd_set

^
In file included from ../../core-common-lib/CC3000_Host_Driver/evnt_handler.h:38:0,
from ../inc/spark_wlan.h:33,
from ../inc/main.h:38,
from ../inc/spark_utilities.h:30,
from ../inc/spark_wiring.h:33,
from ../inc/spark_wiring_stream.h:36,
from ../inc/spark_wiring_client.h:24,
from ../inc/spark_wiring_tcpclient.h:29,
from HttpClient.h:5,
from HttpClient.cpp:1:
../../core-common-lib/CC3000_Host_Driver/socket.h:162:0: warning: "FD_SET" redefined [enabled by default]

define FD_SET(fd, fdsetp) __FD_SET (fd, fdsetp)

^
In file included from /opt/gcc_arm/arm-none-eabi/include/stdio.h:47:0,
from ../inc/spark_wiring_print.h:30,
from ../inc/spark_wiring_string.h:33,
from HttpClient.h:4,
from HttpClient.cpp:1:
/opt/gcc_arm/arm-none-eabi/include/sys/types.h:258:0: note: this is the location of the previous definition

define FD_SET(n, p) ((p)->fds_bits[(n)/NFDBITS] |= (1L << ((n) % NFDBITS)))

^
In file included from ../../core-common-lib/CC3000_Host_Driver/evnt_handler.h:38:0,
from ../inc/spark_wlan.h:33,
from ../inc/main.h:38,
from ../inc/spark_utilities.h:30,
from ../inc/spark_wiring.h:33,
from ../inc/spark_wiring_stream.h:36,
from ../inc/spark_wiring_client.h:24,
from ../inc/spark_wiring_tcpclient.h:29,
from HttpClient.h:5,
from HttpClient.cpp:1:
../../core-common-lib/CC3000_Host_Driver/socket.h:163:0: warning: "FD_CLR" redefined [enabled by default]

define FD_CLR(fd, fdsetp) __FD_CLR (fd, fdsetp)

^
In file included from /opt/gcc_arm/arm-none-eabi/include/stdio.h:47:0,
from ../inc/spark_wiring_print.h:30,
from ../inc/spark_wiring_string.h:33,
from HttpClient.h:4,
from HttpClient.cpp:1:
/opt/gcc_arm/arm-none-eabi/include/sys/types.h:259:0: note: this is the location of the previous definition

define FD_CLR(n, p) ((p)->fds_bits[(n)/NFDBITS] &= ~(1L << ((n) % NFDBITS)))

^
In file included from ../../core-common-lib/CC3000_Host_Driver/evnt_handler.h:38:0,
from ../inc/spark_wlan.h:33,
from ../inc/main.h:38,
from ../inc/spark_utilities.h:30,
from ../inc/spark_wiring.h:33,
from ../inc/spark_wiring_stream.h:36,
from ../inc/spark_wiring_client.h:24,
from ../inc/spark_wiring_tcpclient.h:29,
from HttpClient.h:5,
from HttpClient.cpp:1:
../../core-common-lib/CC3000_Host_Driver/socket.h:164:0: warning: "FD_ISSET" redefined [enabled by default]

define FD_ISSET(fd, fdsetp) __FD_ISSET (fd, fdsetp)

^
In file included from /opt/gcc_arm/arm-none-eabi/include/stdio.h:47:0,
from ../inc/spark_wiring_print.h:30,
from ../inc/spark_wiring_string.h:33,
from HttpClient.h:4,
from HttpClient.cpp:1:
/opt/gcc_arm/arm-none-eabi/include/sys/types.h:260:0: note: this is the location of the previous definition

define FD_ISSET(n, p) ((p)->fds_bits[(n)/NFDBITS] & (1L << ((n) % NFDBITS)))

^
In file included from ../../core-common-lib/CC3000_Host_Driver/evnt_handler.h:38:0,
from ../inc/spark_wlan.h:33,
from ../inc/main.h:38,
from ../inc/spark_utilities.h:30,
from ../inc/spark_wiring.h:33,
from ../inc/spark_wiring_stream.h:36,
from ../inc/spark_wiring_client.h:24,
from ../inc/spark_wiring_tcpclient.h:29,
from HttpClient.h:5,
from HttpClient.cpp:1:
../../core-common-lib/CC3000_Host_Driver/socket.h:165:0: warning: "FD_ZERO" redefined [enabled by default]

define FD_ZERO(fdsetp) __FD_ZERO (fdsetp)

^
In file included from /opt/gcc_arm/arm-none-eabi/include/stdio.h:47:0,
from ../inc/spark_wiring_print.h:30,
from ../inc/spark_wiring_string.h:33,
from HttpClient.h:4,
from HttpClient.cpp:1:
/opt/gcc_arm/arm-none-eabi/include/sys/types.h:261:0: note: this is the location of the previous definition

define FD_ZERO(p) (extension (void)({ \

^
application.cpp:2:18: fatal error: lib2.h: No such file or directory

include "lib2.h"

^
compilation terminated.
make: *** [application.o] Error 1

Veryfing code using this library in Particle Build fails with this error:

HttpClient/HttpClient.cpp:172:37: error: 'millis' was not declared in this scope
     unsigned long lastRead = millis()
HttpClient/HttpClient.cpp:231:22: error: 'delay' was not declared in this scope
             delay(200);
HttpClient/HttpClient.cpp:266:47: error: 'atoi' was not declared in this scope
             aResponse.status = atoi(statusCode.c_str());

Hi,
Great library! I'm noticing that the parsing of the response codes doesn't always work for me. When I get a 200 , it seems to work fine. However when I get a 201 response code, I see the following output:

Application> Start of Loop.
Application> Response status: -1
Application> HTTP Response Body:
Waiting until next time

This is interesting because I can see that my data is actually being sent to my API fine. The status codes just aren't being parsed for some reason. In your inline comments you mention that you are using a non-elegant way of figuring out the status codes. I'm actually considering contributing, if you are open to contributions. I wanted to bring the issue to your attention first though. Thanks again for this great library.

Hi,
thank you for this nice contribution! Had quite some trouble getting my Core speaking with my node express app.
While everything played out nicely, I receive a 5s Timeout on every get or post like for example:

HttpClient>     Receiving TCP transaction of 128 bytes.
HTTP/1.1 200 OK
X-Powered-By: Express
Content-Type: text/html; charset=utf-8
Content-Length: 12
ETag: W/"c-441cfa1a"
Date: Sat, 10 Jan 2015 19:06:49 GMT
Connection: close

Hi from node
HttpClient>     End of TCP transaction.
HttpClient>     Error: Timeout while reading response.

HttpClient>     End of HTTP Response (5602ms).
HttpClient>     Status Code: 200

My node app is generated by express and I am just doing

router.get('/get', function(req, res) {
  res.send('Hi from node');
});

By the way is there an easy way to get rid of the LOGGING define in the Web IDE? Or do I need to fork the library and disable that line manually?

Thanks!

When I tried out the example through Particle's web IDE, I got this output:

Application> Start of Loop.
Application> Response status: 403
Application> HTTP Response Body:

There is no response body. curl returns a valid response, so the connection is not the issue.

After some debugging, I found out that timeapi.org expects a "User-Agent" field in the Http request. Altering the example to this...

http_header_t headers[] = {
{ "Accept" , "*/*"},
{ "User-Agent" , "A user agent."},
{ NULL, NULL }
};'

...gives output:

Application> Start of Loop.
Application> Response status: 200
Application> HTTP Response Body: 2016-12-22T18:41:00+00:00

I downloaded this great code to use locally via the atom software, but when I send it to the cloud for compiling, i get errors 'request' does not name a type at the point when i try to set the hostname and port!

Thanks,

Veryfing code using this library in Particle Build fails with this error:

HttpClient/HttpClient.h:44:3: error: 'http_request_t' has a previous declaration as 'typedef struct http_request_t http_request_t'
 } http_request_t

I can't seem to be able to turn off the logging feature of the library.
I tried using an #undef LOGGING in my application code, but it's not working.
Perhaps you could remove the #define from the library and we can add it later if needed in the application code?
Thanks!

There are numerous discussions on the community.particle.io forums about the use of Arduino-style strings causing possible memory fragmentation. Would it be possible to convert all uses of "String" to a standard C char[] array instead?

Hi,

I don't know if this is the best place to share my thoughts, but I didn't find any Particle room on Gitter.
I am playing with the HttpClient in order to POST some data from my Particle Core to a nodejs http server on my local network.
Globally it works. But It seems that the http.post() method is blocking until timeout. I think it could come from the line 237 of HttpClient.cpp (}while (client.connected() && !timeout && !error);). Let me explain why:

When in local network, the server could potentially respond to a request very quickly. Furthermore, it is stated in Particle reference that client.connected() returns TRUE if the socket is still open OR if there is any data remaining in the RX buffer. So if the server answers quickly, due to line 235 delay(200);, the client is likely to get some data BEFORE client.connected() is called. In my opinion, this could lead to block the http.post request in the do{}while() loop UNTIL timeout. Thereby, I am experiencing this behaviour right now. The POST request is sent in less than 100ms, then the server answers in less than 2ms. After that, I see some traffic (with Wireshark) sur as [PSH,ACK],[RST,ACK],as well as retransmissions for about 5.5 seconds. Finally, the client sends the [FIN,ACK] packet. I tried to address a distant server, the complete request-response is during max 2 seconds.
I also looked at the Particle forum, nobody seems to talk about that issue, maybe I'm totally wrong and misunderstood the TCP protocol. On demand, I can explore further.

Here is the wireshark log: http://s000.tinyupload.com/?file_id=09753784621306542778

I am unable to make HTTPS requests using this library although HTTP requests work fine. Is there going to be support for HTTPS or is there a work around or even an alternate library?

I really wanted to connect my Spark Core to Firebase, if this worked, it would be awesome!!

After a busy time I am back to spark-core development.

I can't get the http-library working on my core. I am testing with the
simple example in the readme, but with different domains (switch.ch,
google.com, etc.) I am not sure if this is because of my spark-core, the firmware upgrade, new wifi-router or isp...

But i only get this in the console:

Application> Start of Loop.
HttpClient> Connection failed.
Application> Response status: -1
Application> HTTP Response Body:

does it work for you most of the time?

Veryfing code using this library in Particle Build fails with this error:

HttpClient/HttpClient.cpp:266:47: error: 'atoi' was not declared in this scope
     aResponse.status = atoi(statusCode.c_str())

Hi Nils

The version of the HttpClient in the particle.io library does not compile for the photon. This was fixed by pull request #20 which has been merged into the master. I asked particle.io why they don't have the latest version and the response was that you would have to resubmit the library.

Is there any chance you could do that. It would save us novices some time trying to figure out what's wrong when we run into this little problem.

Thanks
Tom

Veryfing code using this library in Particle Build fails with this error:

HttpClient/HttpClient.h:76:60: error: 'HTTP_METHOD_GET' was not declared in this scope
         request(aRequest, aResponse, (http_header_t*)NULL, HTTP_METHOD_GET)

Is it possible to pass authorisation credentials?

I am receiving the requests from Spark Core device but not the data. I have tried get and post requests both are not sending the data. Here is the complete code:

#include "HttpClient/HttpClient.h"

/**
* Declaring the variables.
*/
unsigned int nextTime = 0;    // Next time to contact the server
HttpClient http;

// Headers currently need to be set at init, useful for API keys etc.
http_header_t headers[] = {
      { "Content-Type", "text/html" },
    //  { "Accept" , "application/json" },
    { "Accept" , "*/*"},
    { NULL, NULL } // NOTE: Always terminate headers will NULL
};

http_request_t request;
http_response_t response;

void setup() {
    Serial.begin(9600);
}

void loop() {
    if (nextTime > millis()) {
        return;
    }

    Serial.println();
    Serial.println("Application>\tStart of Loop.");
    // Request path and body can be set at runtime or at setup.
    request.hostname = "spark.myapi.com";
    request.port = 80;
    request.path = "/api.php";

    // The library also supports sending a body with your request:
    //request.body = "response={\"deviceID\":\""+Spark.deviceID()+"\", \"statusCode\": 1}";
    request.body = "response=1";

    // Get request
    http.post(request, response, headers);
    Serial.print("Application>\tResponse status: ");
    Serial.println(response.status);

    Serial.print("Application>\tHTTP Response Body: ");
    Serial.println(response.body);

    nextTime = millis() + 10000;
}

First off, thank you for such a great HttpClient library! Using content-length has sped up HTTP requests in our projects quite a bit, especially on slower networks where we had to use slightly larger timeouts.

There appears to be a race condition present between the check for client.available() and and check for client.connected().

Symptom: Requests to a server would read the headers and up to about 20 bytes of the body, but would return error (-1) prematurely.

I debugged it and saw that client.available() returned false when the read buffer was empty though more data was expected. The subsequent call to client.connected() would then return false; 'timeout', 'error', and 'done' were all false at that time. Calling client.available() after that loop returned true. So data was placed in the buffer after client.available() returned false, but before client.disconnected() was called.

I commented out the call to client.connected() in the outer loop and it became rock-solid (relying on the timeout to break):

} while (/*client.connected() && */!timeout && !error && !done);
One possible fix is to call client.available() in the outer loop:

} while (client.available() || (client.connected() && !timeout && !error && !done));
To ensure it completely drains the read buffer even after the connection is closed.

I'm trying to call a local IP but no success. I can call the same server if I forward the port and use the external IP. however using the local IP I cannot get any connection - Any idea why this may be?