> > > > according to the spec (linked in the above SO thread) the Location header should be sent URL encoded, hence decoding it is wrong.. > > We dequoted the URI because the URI is quoted again afterwards. Not all characters > are quoted, though, but at least a %3B would be quoted as %253B. > > See commit c34ea12ad509cb34c954ed574a301c3cbede55ec and Bug#602412 for details.
Hi, While it is understandable why the current logic makes this fix less trivial, I am concerned that the basic working assumptions behind this logic are broken. First, without understanding the URL parts before decoding, re-encoding (what is referred here as "quoting") back to the original form cannot be done is a symmetric way to give back the same semantics. Please see the following link for more details: https://www.talisman.org/~erlkonig/misc/lunatech%5Ewhat-every-webdev-must-know-about-url-encoding/#DecodedURLscannotbereencodedtothesameform Second, it is the HTTP 1.1 spec that mandates the Location header's URL to be encoded, so it is a reasonable expectation from the server standpoint for clients to treat the Location value as a legally encoded URL. The fix mentioned above is breaking this assumption by re-applying encoding in a way that is changing the original URL semantics. > > I'd advise you to not use URIs involving percent-encoded characters or provide a patch > and a test case if you want to see this (actually minor) issue fixed. > > As a data point, all the official mirrors and redirectors work fine. Surely, one cannot avoid using legitimate encoded URLs as solution. With hundreds of User-Agent types, currently apt is the only agent that does not follow redirects as advised by the spec and we had to implement a server side workaround for it (basically not serving redirects). So, I'd urge the apt library to do the right thing and treat the Location header as an encoded URL ready to be used as is without further manipulation. I hope this makes sense.
