determine if server supports resume get request

Question

How does one determine if a server supports resuming a file transfer or get request?

My thoughts were to set the header to start the get request at byte "2" instead of 0, and immediately closing the http request if that gave the proper result

but I was wondering if there was something about the server response for a different kind of probe that would reveal this information to me

Solution 1

To probe the download resume feature of a server, you may send a HEAD request to the server supplying a Range header with arbitrary values. If the response code is 206, then resume is supported.

Example with curl:

$ curl -i -X HEAD --header "Range: bytes=50-100" http://mirrors.melbourne.co.uk/ubuntu-releases//raring/ubuntu-13.04-desktop-amd64.iso

Update:

Here's an example in Java:

import org.apache.http.client.ResponseHandler;
import org.apache.http.client.HttpClient;
import org.apache.http.HttpResponse;
import org.apache.http.client.methods.HttpHead;
import org.apache.http.impl.client.DefaultHttpClient;
import org.apache.http.message.BasicHeader;

public class ResumeChecker {

    public final static void main(String[] args) throws Exception {

        HttpClient httpclient = new DefaultHttpClient();
        HttpHead httpRequest = new HttpHead("http://www.google.com");
        httpRequest.addHeader(new BasicHeader("Range", "bytes=10-20"));

        System.out.println("Executing request " + httpRequest.getURI());

        HttpResponse response = httpclient.execute(httpRequest);

        // Check here that response.getStatusLine() contains 206 code
    }
}

However, I haven't tested it mysqlf.

Solution 2

Adding to @aadel's answer:

Most of the servers nowadays respond with Accept-Ranges: bytes header in case they support resuming. Postman, RequestMaker or Insomnia can help you in examining request/response headers.

Comments

[Corrodias]

I have seen - active, in the wild - servers that respond with Accept-Range: bytes but still don't support ranged downloads (at least, maybe for some files but not all of them). Sending a request with Range gets you a 200 and the entire file rather than a 206 with just the part you requested. They might be due to badly-written HTTP/HTTPS proxies. Moral of the story: don't trust the headers. Make the HEAD request anyway. Or double-check the response code of the GET.

[Corrodias]

Correction to my last comment: It isn't necessarily badly-written. A 200 is a valid response if your If-Range header indicates that you're requesting a different version of the file from what the server has. Still, the takeaway is that a 200 is a valid response to a Range request.

[TheRealChx101]

@Corrodias But it still means you may end up corrupting a file if the first part of it was already downloaded and then the server returns the first part again, which you end up appending to the local file.