[bug #60106] wget mistakenly interprets Content-Range as bytes, even with Range-Unit: items, and truncates content

Update of bug #60106 (project wget): Status: Invalid => Confirmed Open/Closed: Closed => Open ___ Follow-up Comment #5: Thanks for reporting t

[bug #60106] wget mistakenly interprets Content-Range as bytes, even with Range-Unit: items, and truncates content

Follow-up Comment #4, bug #60106 (project wget): (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.)

[bug #60106] wget mistakenly interprets Content-Range as bytes, even with Range-Unit: items, and truncates content

Follow-up Comment #3, bug #60106 (project wget): So you'd say 'curl' is wrong by not doing the same as 'wget' here? And what about this aspect: > 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 b

[bug #60106] wget mistakenly interprets Content-Range as bytes, even with Range-Unit: items, and truncates content

Update of bug #60106 (project wget): Status:None => Invalid Open/Closed:Open => Closed ___ Follow-up Comment #2: Hi, As far as I can t

[bug #60106] wget mistakenly interprets Content-Range as bytes, even with Range-Unit: items, and truncates content

Follow-up Comment #1, bug #60106 (project wget): The problem occurs even when a valid 'Content-Length' header is present in the response. For example, GET on this URL returns something like 10 'company' items: https://example.form.io/company/submission ___

[bug #60106] wget mistakenly interprets Content-Range as bytes, even with Range-Unit: items, and truncates content

URL: Summary: wget mistakenly interprets Content-Range as bytes, even with Range-Unit: items, and truncates content Project: GNU Wget Submitted by: afranke Submitted on: Tue 23 Feb 2021 07:10:59 PM U