search

GerHobbelt / mootools-filemanager

A filemanager for the web based on MooTools that allows you to (pre)view, upload and modify files and folders via the browser.
http://cpojer.net/blog/MooTools_based_FileManager
Other
4 stars 1 forks source link

jsGET issue? walk around dirtree with lots of spaces, etc. in dir & filenames and # will carry cruft #6

Closed GerHobbelt closed 13 years ago

GerHobbelt commented 13 years ago

After browsing through a image collection with directories and filenames which have spaces in them, and a few other non-alpha ASCII characters (not sure this is purely due to the WS in there), the #fm.... bookmark-based storage (jsGET?) gets crufty: it still works well, but among the 'correct' entries, there's a lot of garbage gathering, making the #.... section HUGE after a while and no way to clean up.

The suspect here is jsGET, but that's a hunch. It DOES have real trouble with filenames which carry a # themselves, as the filenames, etc. are stored unencoded and a browser will (FF3 at least) will strip anything beyond the second #, or so it seems.

frozeman commented 13 years ago

Hm i should make the get an sEt method Clearing out the #. I didnt thought about that. St can clean it and get replaced it again to #. Ot i Call urlencode but i think i did.

Tanks for Findung this

GerHobbelt commented 13 years ago

just thinking ahead: cleaning out the #... section entirely might not be desirable at all times: consider the scenario where the fmXXX=YYY storage items are mixed with a real 'fragment' carrying an element ID to jump to...

EDIT: Forget it.

http://www.w3.org/TR/html401/struct/links.html#h-12.2.1

is very specific about fragments for text/html media: using jsGET means the above scenario is non-existent as it would be a illeg cf. the standards.

See also:

http://tools.ietf.org/html/rfc5147#section-1.2

http://tools.ietf.org/html/rfc2854#section-3

so that leaves us with the obscure scenario where jsGET is mixed with other stuff using the fragment section to store arbitrary data.

Furthermore, a bit of testing reveals that, indeed, there are no restrictions on the fragment contents, at least not by the browser (FF3.6.16), so the observed 'losing everything after the second '#' must be a glitch in the jsGET logic - or some other JS.

GerHobbelt commented 13 years ago

fixed in latest commit; jsGET fixes also available in jsGET repo clone.

frozeman commented 13 years ago

Thanks a lot.

GerHobbelt commented 13 years ago

You're welcome!