Description
The metalink file format supports describing file sizes with the <size> element (as described by RFC 5854). This element is optional.
When attempting to download the files described by a metalink file and where the size of the file is included, aria2 appears to use the file's size when forming the HTTP request. In particular, aria2 appears to use this information when deciding to add the Range HTTP request header, and when building that header's value; for example, a request for a 130,023,470 byte file includes the header:
Range: bytes=0-130023469
There are some HTTP servers that reject HTTP requests with a Range HTTP request header.
This appears to be the result of the server not knowing the file's size in advance, as suggested by the server responding with chunked encoding.
Since (in most cases) the entire file's content is desired, the Range HTTP request header should not be needed and could be omitted.
There are (however) some subtle here, as described in RFC 5854:
Note that the "metalink:size" element MUST override the actual content length
of the representation as reported by the underlying protocol, and
those that do not match MUST be discarded by Metalink Processors.
This would imply some post-download check, which Aria2 may already support (I haven't checked).
One possible solution would be for aria2 to support not sending the Range HTTP request header if it is downloading the entire file (i.e., a single segment). This behaviour could be controlled by a command-line option (or other configuration) to allow backwards compatible behaviour (if that is needed), with a suitable default value.
A work-around for this problem involves removing the <size> elements from the metalink file. Without the <size> element, aria2 no longer includes the Range HTTP request header when requesting the file's data and the transfer proceeds.
This work-around is undesirable, though, as it removes one of the most fundamental verification of data integrity: that the file has the correct size.