Associated with changeset 1219548: Initial fix for content_length bug
I was using the December preview of the C++ Azure Storage SDK built on top of Casablanca 1.3.1, and nothing was working for me when trying to read from VHD files stored in Azure blob storage. I tracked down the problem to http_headers::content_length() returning zero when I’m dealing with resources that are greater than 4 gigabytes.
Anyway, looking at the source for http_headers::content_length(), I saw that the ‘length’ variable is a 32 bit value:
```
utility::size64_t http_headers::content_length() const
{
size_t length = 0;
match(http::header_names::content_length, length);
return length;
}
```
The code above seems to always return ‘zero’ if the ‘Content-Length’ header doesn’t fit into a size_t.
I changed the definition of ‘length’ to size64_t and recompiled Casablanca and everything started working. Can you guys confirm whether or not this is a bug, and whether the correct fix really is just changing ‘length’ to size64_t?
I was using the December preview of the C++ Azure Storage SDK built on top of Casablanca 1.3.1, and nothing was working for me when trying to read from VHD files stored in Azure blob storage. I tracked down the problem to http_headers::content_length() returning zero when I’m dealing with resources that are greater than 4 gigabytes.
Anyway, looking at the source for http_headers::content_length(), I saw that the ‘length’ variable is a 32 bit value:
```
utility::size64_t http_headers::content_length() const
{
size_t length = 0;
match(http::header_names::content_length, length);
return length;
}
```
The code above seems to always return ‘zero’ if the ‘Content-Length’ header doesn’t fit into a size_t.
I changed the definition of ‘length’ to size64_t and recompiled Casablanca and everything started working. Can you guys confirm whether or not this is a bug, and whether the correct fix really is just changing ‘length’ to size64_t?