The current streaming API takes a callback function with two parameters:
typedef function<void(boost::iterator_range<char const*> const&,
system::error_code const&)> body_callback_function_type;
This means that from within the body handler, there is no way to know what the HTTP status code was for the underlying request or what the headers were (most importantly the "Transfer-Encoding" header), even though the status code and the headers are parsed before the callback is invoked.
One workaround is to use the callback to simply assemble the body bytes, and then actually parse it after the request completes. This, however, won't work for hanging gets, where the data is coming in incrementally.
I'd like to augment the API to allow the callback to access the underlying http_async_protocol_handler fields (including the promises and is_chunk_encoding), most likely via the underlying response object. There is a way to make it backward compatible by overloading on a 2-parameter callback.
@deanberris, would you entertain a PR with such a change?
The current streaming API takes a callback function with two parameters:
This means that from within the body handler, there is no way to know what the HTTP status code was for the underlying request or what the headers were (most importantly the "Transfer-Encoding" header), even though the status code and the headers are parsed before the callback is invoked.
One workaround is to use the callback to simply assemble the body bytes, and then actually parse it after the request completes. This, however, won't work for hanging gets, where the data is coming in incrementally.
I'd like to augment the API to allow the callback to access the underlying
http_async_protocol_handlerfields (including the promises andis_chunk_encoding), most likely via the underlyingresponseobject. There is a way to make it backward compatible by overloading on a 2-parameter callback.@deanberris, would you entertain a PR with such a change?