URL encoding suggestion pathname's unintended side effect about libkiwix

[veloman-yunkan]

At first sight, I would said that we should not url encode / in the path.

Building suggestion links using URI-encoded components (book name and the article path) was introduced in #860. The main targets were only a few dangerous symbols, however in the absence of a standard function for selective URI-encoding all reserved symbols were encoded leading to this issue.

wonder a bit that we still have URL encoding issues.

@kelson42 The non-homogeneous structure of URLs but the natural desire to keep things simple has resulted in an encoding scheme that makes the world go nuts when one URL has to be embedded in another URL. Therefore there is no surprise that a human mind cannot comprehend all possible interactions of various scenarios (especially when pieces of code from different people having different assumptions meet in one place). Hence, please be prepared for a few more issues of this kind with exponentially growing weirdness until fixing the last one will produce a space-time singularity that will destroy our Universe. 😄

[mgautierfr]

My question at this point would be: why are we URL-encoding this information? From what I understand, this is a ZIM-Entry path that is sent to us via the Suggestion API and we just use it as source of the iframe (prefixed with root if any).
Need for URL-encoding would be to prevent characters from that ZIM entry path to be interpreted as special-meaning for being reserved characters.

We url encode as we may have ? or # being part of the entry path. If we don't url encode the path, the path foo/bar?option=true#section1 would lead to a request for foo/bar, with query string option=true and without section has every thing after the # is not send to the server.

While ZIM path are entirely free, ZIM creators already limit themselves and will do as long as ZIM are mainly run in a Web context.

At least zimit stores the querystring as part of the path (foo/bar?option=true).

---

At first sight, I would said that we should not url encode / in the path.

[kelson42]

@veloman-yunkan This is a must fix before releasing 12.1.0... wonder a bit that we still have URL encoding issues.