I love to see that wget2 downloas the 4027 bytes and saves it as 'submission' ;-)

(Just to clarify: Our current workaround for scripts accessing real-world form.io based sites is to use curl instead of wget. In effect, you are suggesting to make this workaround permanent.)

Hi,

As far as I can tell, the "Range-Unit" header is not mentioned in any of the HTTP/1.1 Specifications (RFC 7230-7237). The correct way to specify the range unit would be to add the unit in the "content-range" header itself. This is very clearly outlined in both RFC2616, the original HTTP/1.1 specification and in RFC7233 the latest version of HTTP/1.1. Please refer to the ABNF provided there to create valid HTTP responses that comform to the specification.

By the specification, if the unit is not specified, the client is allowed to interpret it as Bytes, which is exactly what Wget does.

When a server sends the following response headers:

  Accept-Ranges: items
  Range-Unit: items
  Content-Range: 0-110/111

but no 'Content-Length' response header, then wget says

Length: 111 [...]

and truncates the response content after 111 bytes (or, when using https, after a few KB), even though the full response content is much larger (e.g. 720 KB).

What's worse, --ignore-length doesn't help with this at all.

While a range unit of "bytes" is the most common case, IMO wget should not assume a range unit of "bytes" when the 'Range-Unit' header says something else.

To aggravate the problem even further, wget then retries with a range request for the remaining content using a bytes range, even though the server just stated it does NOT support bytes ranges, but only items ranges.  (This latest problem can be avoided by disallowing retries with the -t1 option.)

This issue can occur e.g. with a REST api providing lists of items as application/json content.