[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Wget-dev] wget2 | Downloading 301 response with space in location f
From: |
Tim Rühsen |
Subject: |
Re: [Wget-dev] wget2 | Downloading 301 response with space in location fails (#420) |
Date: |
Thu, 20 Dec 2018 09:01:13 +0000 |
[ First two comments: 1) Don't use --no-check-certificate if not absolutely
needed 2) add --trust-server-names to the wget command line]
In short: The server is misconfigured
Here is the long answer:
A URI must not contain any spaces (they have to be pct-encoded). In other words
the server doesn't obey the standards. We could accept this, but it leads
directly to a corner case where a file name ends with a space. That falls into
OWS (optional white space) and will be omitted when parsed - that means such a
file name can't be properly transferred with that broken server configuration.
(see also https://greenbytes.de/tech/webdav/rfc7230.html#header.fields)
A short extract from the standard:
A Location: Header is defined as "Location = URI-reference", see
https://tools.ietf.org/html/rfc7231#page-68.
The file name part is defined as "segment" in
https://tools.ietf.org/html/rfc3986:
```
segment = *pchar
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="
```
Of course we can add a work-around and accept spaces in the Location: URI.
--
Reply to this email directly or view it on GitLab:
https://gitlab.com/gnuwget/wget2/issues/420#note_126377416
You're receiving this email because of your account on gitlab.com.