Is there a data limitation in the dlib::outgoing_things HTTP server response? dlib::server_http

[alexandreofbh]

I'm trying to make a webhook. I'm using dlib::server_http. I used the example dlib/examples/server_http_ex.cpp to implement it. However, in the "const std::string on_request(const dlib::incoming_things& incoming, dlib::outgoing_things& outgoing)" function, when the outgoing response exceeds 73,660 bytes, it loses the remainder of the message. Is there a place where I can change this size?
When the size is smaller than 73,660 bytes, it works perfectly.
I would greatly appreciate it if someone could clarify this for me.

[davisking]

See server_http::get_max_content_length(). The docs explain it http://dlib.net/dlib/server/server_http_abstract.h.html#server_http. Although, the default max size is much greater so I don't know what would explain your problem.

[alexandreofbh]

Thank you once again!

[davisking]

No problem :)

[alexandreofbh]

Dear Davis King,

DLib dlib::http_server is working perfectly. And the response buffer size server_http::get_max_content_length() was 10485760 BYTES.

What was going wrong was the client I was using to test the server_http. For some reason, it was truncating the response. I had created it in Java, and the error was fixed when I changed:
(cut-) buffer=new byte[inputStream.available()];
(cut-) inputStream.read(buffer);
(cut-) fileOutputStream.write(buffer);
to:
(add+) while (true) {
(add+) buffer = new byte[inputStream.available()];
(add+) int bytesRead = inputStream.read(buffer);
(add+) if (bytesRead == -1)
(add+) break;
(add+) fileOutputStream.write(buffer, 0, bytesRead);
(add+) }

I don't know why, but it started working after implementing this loop, and this loop runs some times. In other words, for some reason, in Java, the "HttpURLConnection::getInputStream()" from the "import java.net.HttpURLConnection;" delivers fragmented pieces of the received buffer.

This problem has been resolved ok!

Thank you for your attention and for the DLib!

[davisking]

Cool, glad it's working :)

Yeah you definitely need the loop. Since there isn't any way for the read() method to know when the client has sent all the data. So IO libraries return whatever data they have when you call read(), unless there isn't any. So depending what happens you will in general require multiple read() calls. When it works with one you are just getting lucky, but it's a race condition. Like if you slowed down the network you would notice it returning even smaller chucks of data.

[alexandreofbh]

Yeah, that's right!
And the worst part is that the server and the client are on the same machine! I haven't even had a chance to test them on separate machines yet!
Thank you so much for everything, Davis King.

[davisking]

No problem.