bug-wget
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: wget fails with this url


From: Tim Rühsen
Subject: Re: wget fails with this url
Date: Sat, 21 May 2022 12:11:27 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1

On 20.05.22 19:39, Gisle Vanem wrote:
gerdd@mweb.co.za wrote:

I tried this from South Africa and I am getting the exact behaviour as the OP.

Okay. Now I tested with various other older Wgets:
   the one bundled with Ruby (a msys2 built version) -> 403 Forbidden
   the one bundled with GNU Octave-6.4 -> 403 Forbidden
   Lumito's 'wget2.exe', same bleeding 403.

I forgot to state, I got no '403' with my home-built
Wget from git master (on Windows-10). So this is probably
a bug that's been fixed. So you could upgrade and try
again.

Thanks for your tests.
I also think this is something (not necessarily a bug) that has been fixed or at lest changed.

Interestingly, wget2 seems to have the same (or a similar) issue.

The 'Location:' header in the redirection contains several '+' chars in the query part. Internally, these get unescaped to ' ' (space) and later, for the GET, the spaces are escaped to %20 by wget2 and to '+' by current wget.

For some servers this makes a difference, others don't care (%20 and '+' should be unescaped to space on the server side). I can imagine that performance-optimized caching proxies skip the normalization and take the input as-is to perform the lookup.
In other cases, wget2 may succeed with %20 while wget doesn't with '+' !?
I might have to rethink normalization / escaping...

Regards, Tim

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]