Update of bug #60106 (project wget):
Status: Invalid => Confirmed
Open/Closed: Closed => Open
_______________________________________________________
Follow-up Comment #5:
Thanks for reporting this.
Just skimmed the specs ... well, the server is special in several ways and
seems to interpret standards "in his own way".
I'd even say it's simply buggy and should be fixed.
(E.g. the "Content-Range:" format is simply wrong regarding
https://tools.ietf.org/html/rfc7233#section-4.2).
Anyways, wget should simply ignore the broken and the undefined HTTP headers
and save the response body. The Content-Length header gives all the
information needed (4027 bytes in the example below). I am sure that curl does
exactly that.
The unregistered (private) Range-Unit header is already ignored by wget, so it
has nothing to do with this issue. The title of this issue was possibly a bit
misleading, so I'll amend it.
I'll reopen the bug, as IMO we should fix the behavior of wget here.
HTTP/1.1 206 Partial Content
Accept-Ranges: items
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: Content-Range, Accept-Ranges, Range-Unit
Cache-Control: no-cache,max-age=0
Content-Range: 0-9/25
Content-Type: application/json; charset=utf-8
Date: Sat, 13 Mar 2021 17:35:04 GMT
ETag: W/"fbb-DQKITUXXr7c2bHQ0GXXQJaUxUwg"
Link: </form/5b8c1017edc1a6c05601af8e/submission>; rel="next"; items="10-34",
</form/5b8c1017edc1a6c05601af8e/submission>; rel="last"; items="20-44"
Range-Unit: items
Server: nginx/1.16.1
Vary: Origin
X-Powered-By: Express
Content-Length: 4027
Connection: keep-alive
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?60106>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
