Http Range solicitud de propiedad?

Question

Nov 04, 2016, 09:34 AM

Http Range solicitud de propiedad?

Estoy atascado escribiendo algunas piezas de código Java tratando de descargar por rango un archivo de destino desde un host remoto. Espero descargar archivos remotos por algunos fragmentos que dependen de algún proceso multiproceso.

Según el seguimiento de depuración, todo funciona bien:

Task 2 --> REQUEST PROPERTIES =  {Range=[bytes=59124782-88687172]}
Task 3 --> REQUEST PROPERTIES =  {Range=[bytes=88687173-118249563]}
Task 0 --> REQUEST PROPERTIES =  {Range=[bytes=0-29562390]}
Task 1 --> REQUEST PROPERTIES =  {Range=[bytes=29562391-59124781]}
Task 2 --> RETURN_CODE = 206 ==> OK :-) !
Task 2 --> Start Byte = 59124782 / End Byte = 88687172 --> Total bytes = 29562391
Task 0 --> RETURN_CODE = 206 ==> OK :-) !
Task 0 --> Start Byte = 0 / End Byte = 29562390 --> Total bytes = 29562391
Task 3 --> RETURN_CODE = 206 ==> OK :-) !
Task 3 --> Start Byte = 88687173 / End Byte = 118249563 --> Total bytes = 29562391
Task 1 --> RETURN_CODE = 206 ==> OK :-) !
Task 1 --> Start Byte = 29562391 / End Byte = 59124781 --> Total bytes = 29562391

De acuerdo con el siguiente seguimiento de depuración, todo NO funciona bien:

Task 0 --> REQUEST PROPERTIES =  {Range=[bytes=0-15308169]}
Task 3 --> REQUEST PROPERTIES =  {Range=[bytes=45924510-61232679]}
Task 1 --> REQUEST PROPERTIES =  {Range=[bytes=15308170-30616339]}
Task 2 --> REQUEST PROPERTIES =  {Range=[bytes=30616340-45924509]}
Task 0 --> RETURN_CODE = 206 ==> OK :-) !
Task 0 --> Start Byte = 0 / End Byte = 15308169 --> Total bytes = 15308170
Task 3 --> RETURN_CODE = 200 ==> NOK :-( !
Task 2 --> RETURN_CODE = 200 ==> NOK :-( !
Task 1 --> RETURN_CODE = 200 ==> NOK :-( !

El truco es entre 2 ejecuciones, el código es el mismo, el host remoto es el mismo ... solo el archivo de destino no es el mismo (el segundo es medio más pequeño que el primero y ambos son archivos .zip). Al solicitar un rango definido, espero que para cada tarea 206 se devuelva el código de retorno que reconoce datos parciales. Pero confiando en la segunda traza que obtengo para el último código de la tarea 200, lo que significa que la respuesta del servidor está bien, pero enviará el archivo completo :-( ....

¿Qué rey de la magia negra puede conducir a tal ????. Buscando en Google un poco, encontré que algunos servidores http pueden introducir algún proceso de fusión de solicitudes de rango ... ¿Puede suceder esto aquí?

Cuando se solicitan varios rangos, un servidor PUEDE unir cualquiera de los rangos que se superponen, o que están separados por un espacio que es más pequeño que la sobrecarga de enviar múltiples partes, independientemente del orden en el que apareció la especificación de rango de bytes correspondiente. el campo de encabezado Range recibido. Dado que la sobrecarga típica entre las partes de una carga útil multiparte / byteranges es de alrededor de 80 bytes, dependiendo del tipo de medio de la representación seleccionada y la longitud del parámetro límite elegido, puede ser menos eficiente transferir muchas partes pequeñas e inconexas que transferir todo el seleccionado representación.

Solo para información aquí está mi código java:

HttpURLConnection urlConn = null;
try {
    urlConn = task.openConnection(task.getSourceFileUrl());
    urlConn.setRequestMethod("GET");
    urlConn.setRequestProperty("Range", "bytes=" + currentByte + "-" + endByte + "");

    System.out.println(String.format("Task %s --> REQUEST PROPERTIES =  %s", id, urlConn.getRequestProperties().toString()));

    if (urlConn.getResponseCode() != HttpURLConnection.HTTP_PARTIAL) {
        System.out.println(String.format("Task %s --> RETURN_CODE = %s ==> NOK :-( !", id, urlConn.getResponseCode()));
        return;
    } else {
        System.out.println(String.format("Task %s --> RETURN_CODE = %s ==> OK :-) !", id, urlConn.getResponseCode()));
    }

    System.out.println(String.format("Task %s --> Start Byte = %s / End Byte = %s --> Total bytes = %s", id, currentByte, endByte, urlConn.getContentLengthLong()));

Gracias por la ayuda !!!!!