GitLab's API uses %2F in its URLs. For example, https://gitlab.com/api/v4/projects/foo%2Fbar refers to the user foo's project named bar.
Wget2 2.1.0 seems to implicitly convert "%2F" strings in URLs to "/". Here is an example:
$ nc -l 8080 -k &
[1] 18734
$ wget --progress=none --server-response -O - --header "Private-Token: x" http://localhost:8080/api/v4/projects/foo%2Fbar
[0] Downloading 'http://localhost:8080/api/v4/projects/foo%2Fbar' ...
GET /api/v4/projects/foo/bar HTTP/1.1
Host: localhost
Accept-Encoding: gzip, deflate, br, zstd
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: wget2/2.1.0
Connection: keep-alive
Private-Token: x
In this example, nc prints the GET request received from wget. Notice that it contains foo/bar, not foo%2Fbar as intended. I would expect that wget would URL encode URLs, but not URL DEcode URLs, as this example demonstrates.
I tried Wget 1.24.5, and it behaved as I would expect: it left the %2F intact when it sent its GET request.
GitLab's API uses %2F in its URLs. For example,
https://gitlab.com/api/v4/projects/foo%2Fbarrefers to the userfoo's project namedbar.Wget2 2.1.0 seems to implicitly convert "%2F" strings in URLs to "/". Here is an example:
In this example,
ncprints the GET request received fromwget. Notice that it containsfoo/bar, notfoo%2Fbaras intended. I would expect that wget would URL encode URLs, but not URL DEcode URLs, as this example demonstrates.I tried Wget 1.24.5, and it behaved as I would expect: it left the
%2Fintact when it sent its GET request.