Florent Daigni?re (NextGen$) wrote: > from frost: > > ----- Anonymous ----- 2007.03.01 - 15:08:23GMT ----- > > I keep seeing weird things with spaces and %20. Some links to indexes appear > with spaces, some others with %20; some file names keep their spaces and some > others no. > > Should this be working? If I remove all indexes and recreate them, should > they appear without %20? > > I don't think Thaw should ever expose in the GUI the internal html escaping > to users, is frankly bothersome. > > ----- Anonymous ----- 2007.03.03 - 00:02:35GMT ----- > > This is ultimately a design problem with the node. For some reason, they > decided to specify Freenet keys as URIs, which means that lots of characters > have to be HTTP-encoded, even if they go nowhere near a web browser or > anything that uses HTTP. Personally, I think it would have been better to > allow Freenet keys to contain any characters. > > The problem is, if Thaw is presented with a key like this: CHK at > .../a%20b.html > > the user might mean a file called "a b.html" (with a space and encoded) > but it might be a file actually called "a%20b.html" > Thaw has absolutely no way of knowing. > > If you have indexes you created yourself and they have %20s in them, here is > how to get rid of them: > > Right-click on the file(s) which have %20s in then and select "Copy keys to > clipboard". > Now right-click on the index name in the left panel and select "Files/Add > specific key(s)". > Paste in the files you just copied to the clipboard. They should now appear > without the %20s. > Now delete the original files with the %20s in. > Upload the new version of your index: right-click, Index/[Re]insert this > index on Freenet. > > ----- Anonymous ----- 2007.03.03 - 13:42:25GMT ----- > > Isn't the node strict in what it generates? If it always returns http-encoded > URIs, then Thaw should assume the keys it's presented are too. Just decode > them for GUI presentation. > > ----- Anonymous ----- 2007.03.06 - 09:34:59GMT ----- > > The problem is that a lot of other apps export keys without http-encoding. I > think this is sensible, because it makes it difficult to read file names if > they are full of %20's and other codes. > > Here is a heuristic algorithm that will work for most cases: > > 1) see if the key has a % sign in the filename part (after the first /) > 2) if it has, assume the filename is http-encoded > 3) is it isn't assume the filename isn't http-coded. > > You also have the possiblilty that things like the @ or commas are > http-encoded, even though it isn't strictly necessary. > > This will fail for files that genuinely do have a % character in the filename > e.g. "I Feel 100%.mp3" but I think it is impossible to decide totally > accurately. > > ----- Anonymous ----- 2007.03.06 - 11:38:29GMT ----- > > I'd prefer if the node were strict and we got rid of this problem once and > for all: the node should reject any non-correctly encoded URL. This would > force client programs to properly encode and decode things. > > It's a small pain to have to look at keys with lots of %20 in them, but this > is only transitory. Once in Thaw or Frost, they should be displayed decoded > to the user. > > ################################### > > Any thought ? > I don't know if it's ever been said that the node always talks about keys as HTTP URI encoded, but if it does, then it should reject any input key that's not properly HTTP URI encoded. Considering that a URI given us via the FProxy web form will be HTTP URI encoded by the sending browser, all sources could be treated the same if we expect all key interactions with the node to be HTTP URI encoded. Then all the clients are forced to treat them the same when talking with the node and present them unencoded to their users, as the node should do via FProxy, as appropriate.
If it hasn't ever been authoritatively said that keys are always HTTP URI encoded when talking with the node, then the node should do minimal encoding as required by the specific protocol being used to talk with a client: i.e. HTTP URI encoding as appropriate when FProxy is doing the talking and maybe backslash encoded for \n via FCP (with no other encoding)? In any case, a decision needs to be made if it hasn't already and once that decision is made, it should be very clearly spelled out in the appropriate specs. The node should not accept input that's not compliant with the spec (perhaps after a month or two of transition time is allowed). Once it's in the spec, clients that don't conform to the spec are considered broken, are fixed and then the problem is gone forever. Even if it hasn't been authoritatively said that keys are always HTTP URI encoded when talking with the node, if most client authors are assuming that now, then perhaps that's what the spec should be (and the node reject incorrectly encoded after a transition time).
