-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
jsGET issue? walk around dirtree with lots of spaces, etc. in dir & filenames and # will carry cruft #6
Comments
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 |
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: 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. |
fixed in latest commit; jsGET fixes also available in jsGET repo clone. |
Thanks a lot. |
You're welcome! |
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.
The text was updated successfully, but these errors were encountered: