How to post with HTTPClient?

I am trying to get the HTTPClient library to work and I can’t figure out how to send this HTTP request to the server.

I have checked with Wireshark on the receiving side and I can see a different set of packets when HTTPClient tries to send the request. This is the request I can send from my browser and it works.

This is the code I am using to test this.

http_request_t request;
http_response_t response;

request.ip = {192,168,1,125};
request.port = 8050;
request.path = "/JSON?request=controldevicebyvalue&ref=37&value=1";

http.get(request, response, headers);'

And I use the following headers.

http_header_t headers[] = {
    { "Accept" , "*/*"},
    { "Content-Type", "text/html"},
    { NULL, NULL } // NOTE: Always terminate headers will NULL

The output on the serial port debug shows this:

HttpClient>	Connecting to IP:
HttpClient>	Start of HTTP Request.
GET /JSON?request=controldevicebyvalue&ref=37&value=1 HTTP/1.0
Connection: close
Accept: */*
Content-Type: text/html
HttpClient>	End of HTTP Request.

HttpClient>	Error: Timeout while reading response.

HttpClient>	End of HTTP Response (5058ms).
HttpClient>	Status Code:
HttpClient>	Error: Can't find HTTP response body.
Status = -1
Body =

What am I missing as the server never acts upon this or sends back a reply?

I’ve noticed that with the HTTPClient library all of the data sent to the server is split up into smaller packets. All the data is in the right format though and the server is responding to the connect but it somehow does not either like what it sees or I am missing something in the packet headers etc. I can see it closing the connection on completion.

With the browser method I can see 1 single packet with all the data and then I see a reply from the server, then it handles the close.

I am wondering if the break up is an issue but I was on the understanding that TCP/IP handles this for you. Maybe not in the case of my server? (Homeseer 3)

Below is what wireshark shows for the browser packet.

GET /JSON?request=controldevicebyvalue&ref=17&value=1 HTTP/1.1
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2457.0 Safari/537.36
DNT: 1
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8,id;q=0.6,ms;q=0.4

This is what I send from the core:

GET /JSON?request=controldevicebyvalue&ref=37&value=1 HTTP/1.0
Connection: close
Accept: text/html
Content-Type: text/html
User-agent: Particle HttpClient

There are some stuff missing but I don’t see any of it being critical to the the server seeing this data.


The HTTPCLIENT library seems to send a lot of packets. There is even 2 packets just to send carriage return and line feed, one in each packet.

I counted 8 packets (this is both ends) for the browser and 63 for the core. :frowning:

I do not know for sure but I have been in situations where the accept parameter was the issue I had to duplicate it to get my connection to work.

@v8dave, if you search I believe there is a “faster” HTTPClient library that uses buffered Client.write() calls to write whole packets instead of using Client.print().

Thanks @peekay123 I’ll have a look but I finally gave up on the library and rolled my own where I build up the packet first and then transmit it. That now works. I will however have a look for the faster library and see if it works too.

String packet;

packet = "GET " + msg + " HTTP/1.0\r\n";
packet += "Host:\r\n";
packet += "Connection: Close\r\n";
packet += "Content-Length: 0\r\n";
packet += "Accept: text/html\r\n";

Then I connect and send it.

if(client.connect("", 8050))
    client.print("\r\n"); // Terminate the packet

It must be something to do with the broken packets as the above is less than what the library was sending.

Good thing too as I need the lights to work before the wife gets back from holiday. :slight_smile:

1 Like

The only faster one I could find was this. It still uses the client.print() to send causing lots of packets. Receive is faster apparently.

I’ll see if I can find something else as I didn’t see any client.write() commands in that one.

1 Like