[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: wget | error 403 (#10)
From: |
wbtcpip2 (@wbtcpip2) |
Subject: |
Re: wget | error 403 (#10) |
Date: |
Sat, 21 May 2022 10:28:22 +0000 |
wbtcpip2 commented on a discussion:
https://gitlab.com/gnuwget/wget/-/issues/10#note_955363764
Because it’s something related to the os language in use. If the OS is in
Italian language –no-iri is required
<details><summary>...</summary>
Da: gitlab@mg.gitlab.com <gitlab@mg.gitlab.com>
Inviato: sabato 21 maggio 2022 12:25
A: info@mbsoft.biz
Oggetto: Re: wget | error 403 (#10)
<https://gitlab.com/rockdaboot> Tim Rühsen
<https://gitlab.com/gnuwget/wget/-/issues/10#note_955363313> commented:
GTN :-)
Btw, wget 1.21.3 does work correctly from my Linux box even without that option
set.
For completeness, here is the text from an email I just sent to the mailing
list:
On 20.05.22 19:39, Gisle Vanem wrote:
> gerdd@mweb.co.za <mailto: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...
—
Reply to this email directly or
<https://gitlab.com/gnuwget/wget/-/issues/10#note_955363313> view it on GitLab.
You're receiving this email because of your account on gitlab.com. If you'd
like to receive fewer emails, you can
<https://gitlab.com/-/sent_notifications/REDACTED/unsubscribe> unsubscribe from
this thread or adjust your notification settings.
</details>
--
Reply to this email directly or view it on GitLab:
https://gitlab.com/gnuwget/wget/-/issues/10#note_955363764
You're receiving this email because of your account on gitlab.com.
- wget | error 403 (#10), wbtcpip2 (@wbtcpip2), 2022/05/20
- Re: wget | error 403 (#10), wbtcpip2 (@wbtcpip2), 2022/05/21
- Re: wget | error 403 (#10), wbtcpip2 (@wbtcpip2), 2022/05/21
- Re: wget | error 403 (#10), @rockdaboot, 2022/05/21
- Re: wget | error 403 (#10),
wbtcpip2 (@wbtcpip2) <=
- Re: wget | error 403 (#10), @rockdaboot, 2022/05/21
- Re: wget | error 403 (#10), @rockdaboot, 2022/05/21
- Re: wget | error 403 (#10), @rockdaboot, 2022/05/21