Re: [Wget-dev] wget2 | Downloading 301 response with space in location fails (#420)

[Tim Rühsen]

[ 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.