[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: wget | error 403 (#10)
From: |
@rockdaboot |
Subject: |
Re: wget | error 403 (#10) |
Date: |
Sat, 21 May 2022 11:08:14 +0000 |
Tim Rühsen commented:
The point is, if you are not using a utf-8 charset and --iri is enabled (e.g.
by default), each URL is translated into UTF-8 by `locale_to_utf8()`. This
function calls `url_unescape_except_reserved()` which unescapes all characters
that doesn't need to be escaped. In your example it is %21 and %7E (exclamation
mark and tilde). When the GET request is generated, these characters are not
escaped again. So the URL is a different string (same URL but slightly
differently encoded) send to the cloudfront proxy, which does not do a
normalization/decoding and thus can't find the new string in his lookup table.
IMO, this is pretty much a cloudfront stupidity in combination with wget trying
to do the best for the user.
--
Reply to this email directly or view it on GitLab:
https://gitlab.com/gnuwget/wget/-/issues/10#note_955371872
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), @rockdaboot, 2022/05/21
- Re: wget | error 403 (#10), @rockdaboot, 2022/05/21
- Re: wget | error 403 (#10),
@rockdaboot <=