Skip to content
This repository was archived by the owner on Jun 1, 2026. It is now read-only.
This repository was archived by the owner on Jun 1, 2026. It is now read-only.

Exception from handle_write_large_body  #19

Description

Migrated from Codeplex: https://casablanca.codeplex.com/discussions/647518

niamurph wrote:

I am using cpprestsdk 2.6 and getting an exception with the description "Unexpected end of request body stream encountered before Content-Length satisfied.". It is thrown from the function handle_write_large_body. My suspicion is that there may be a concurrency issue in the web::http::client::http_client ( or maybe I am using it wrong).

Hitting the exception means that my request never gets sent.

I am running on Mac OS X 10.10.
By adding some logging statements I can see a buffer (boost::asio::buffer) of 90 bytes being written and then read. Usually a single read and a single write. But occasionally there is a second read, and since the buffer is already read, it retuns 0 leading to the path that hits the exception. The exception message says the size is wrong, but I think some concurrency issue has led to the buffer being read one more time after it has already finished.

I think it may be a concurrency issue, since I can avoid it by using a new connection for every message I send. If I reuse a web::http::client::http_client for multiple messages to the same server, then I hit this issue. Maybe I need to check that there are no messages still being processed for the http_client before I queue up another message to the same client, but I do not know how to do that.

Are there any known issues like this. My workaround for the moment is to create a new web::http::client::http_client for every message. That is probably not as good for performance. I can live with the workaround, but I would be keen to find the root cause.

Activity

  1. ndpmurphy commented on Nov 20, 2015

    @ndpmurphy

    Our issue was that we were reusing the http_client when the URL had not changed. However in some cases the headers had changed. What seems to be happening was that the headers for the second message were set by our application before the first message had finished sending, and so some corruption of buffers occurred. My guess is that what we were trying to do is not supported. If anyone knows otherwise, post it here. Otherwise I will stick with my fix - which is not not reuse the http_client at all. And if there is no response shortly I will close this issue.

  2. kavyako commented on Dec 1, 2015

    @kavyako
    Contributor

    We have not come across this issue before.
    I would really appreciate a small repro (or sample code) showing how you are using the http_client for multiple requests, what streams or stream buffers are used etc. It might help us try out and narrow down the issue.

    Kavya.

  3. added a commit that references this issue on May 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions