GeezerVison

I think you can use an enum class here instead.

Yeah, this is a really long line. We prefer using clang-format to make sure we have consistent formatting in the project, so if you don't mind running this patch through it, that would be really good for readability.

Can you help me understand this math?

If range has a size of 1024, this means chunk_size is shifted left 4096 times?

Yes, but range must correspond to the number of digits and 1024 digits would be an unrealistically large number (it would not throw an error though cause there is no overflow checking). I replaced the '+' with a '|' to make it more clear that this expression is just about appending the new bits to the lower end (and shifting the existing bits by the number of the new bits). Every hex digit corresponds to a quadruple of bits, that's why i multiply the number of digits by four. I didn't want to introduce another char buffer to accumulate the hex digits, so I decided to incrementally compute the chunk size.

Consider just removing these lines?

I know this might be out-of-scope, but could you make this point to cpp-netlib.org instead? That would be great, thanks. :)

Unfortunately cpp-netlib.org does not yield chunk encoded content. It does not matter much for this particular test, but for the streaming test we'd have all scenarios covered with www.boost.org: it yields chunk encoded content for http/1.1 clients and non encoded content for http/1.0 clients.

Ah, good point, thanks.

@umennel Careful -- this actually breaks previous behavior. Now, unless you set remove_chunk_markers to true, the following code will produce a chunked-encoded string:

http::client client;
http::client::request request("http://www.boost.org:80/");
http::client::response response = client.get(request);
std::cerr << body(response) << std::endl;

@deanberris Is this what we want?

To put it another way, can you think of a case where we wouldn't want remove_chunk_markers to default to true?

@igorpeshansky, indeed, the default should be true. Otherwise it is hard to keep the behavior consistent. We should decide on this before merging into 0.13.

Great, I'll send a PR shortly.

Sent #830.