-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/30606/#review73096
-----------------------------------------------------------



3rdparty/libprocess/3rdparty/stout/include/stout/net.hpp
<https://reviews.apache.org/r/30606/#comment119298>

    Can we clarify that we'll issue HEAD request?



3rdparty/libprocess/3rdparty/stout/include/stout/net.hpp
<https://reviews.apache.org/r/30606/#comment119299>

    There is an issue with deflated responses. Content-Length can differ like a 
lot from uncompressed body. Do we somehow handle this case?
    If not - can we leave a comment about that?
    
    JFYI, there's Cteonnt-Length header, which containes uncompressed content 
size (not sure how widely it is used).


- Nikita Vetoshkin


On Feb. 18, 2015, 8:01 a.m., Bernd Mathiske wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/30606/
> -----------------------------------------------------------
> 
> (Updated Feb. 18, 2015, 8:01 a.m.)
> 
> 
> Review request for mesos, Adam B, Benjamin Hindman, Till Toenshoff, and 
> Timothy Chen.
> 
> 
> Bugs: MESOS-2072
>     https://issues.apache.org/jira/browse/MESOS-2072
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Adds net::contentLength(). This makes a short HTTP request to read the 
> "content-length" field from the HTTP header.
> 
> This will be used to determine the size of a file before downloading it to 
> the fetcher cache, in order to ensure there is enough space ahead of time.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/3rdparty/stout/include/stout/net.hpp 
> b464e517bb1e7b6b381c6cd6c0466ed788a82615 
> 
> Diff: https://reviews.apache.org/r/30606/diff/
> 
> 
> Testing
> -------
> 
> Used this function in the context of my implementation of MESOS-2072 and 
> MESOS-2074. It correctly reported the content length from an HTTP server 
> constructed from libprocess primitives.
> 
> 
> Thanks,
> 
> Bernd Mathiske
> 
>

Reply via email to