Skip to content
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

Closed
GerHobbelt opened this issue Mar 24, 2011 · 5 comments

Comments

@GerHobbelt
Copy link
Owner

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
Copy link

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
Copy link
Owner Author

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
Copy link
Owner Author

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

@frozeman
Copy link

Thanks a lot.

@GerHobbelt
Copy link
Owner Author

You're welcome!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants