-
Notifications
You must be signed in to change notification settings - Fork 412
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
Custom category names seem to not be escaped in HTML #945
Comments
There are two distinct issues here. One is the filename, the other is the link. FilenameWay back when However, it has been a while since then. Does that decision need to be rethought? What do others think? LinkThe |
I’d say the filename should avoid characters the browser will display encoded in the address, and ones that are definitely illegal as they have special meanings to the browser or filesystem, although that also means spaces would have to be substituted which some might feel is pretty ugly. Markdown docs pages seem do this already as Worth noting Firefox seems to display literal spaces in the address bar while Chrome and Safari leave it as Hrefs definitely should be encoded no matter what, you’d expect anything you throw at it to just work. It’s impossible to use a character needing escaping as it is now, and I can’t use |
Percent encoding is intended to be analogous to network byte order. (The same goes for Punycode for the domain part.) All HTTP traffic is supposed to use it to make sure it can pass through any ancient gateway it encounters along the way, but the intention is that local operations should all use the native format: Unicode. Users are supposed to only ever see the characters themselves, and data is supposed to remain in that way right up until the request is sent, and be decoded immediately when it is received. This is particularly important, because percent encoding breaks when moved from a string in one text encoding to one in another, such as by copy‐and‐paste. Every browser is responsible to display the address in its decoded form. Not doing so is a dangerous bug (see the end of the last paragraph). Once they all follow the rules, there will be no characters displaying as gibberish ever. In reality though, browsers aren’t necessarily caught up to the standard, so in practice 99.99991% of scalars are vulnerable to appearing in encoded form. Even the Note that when I just tested it with Safari,
I had not noticed that before, but looking closer at it now, this is in and of itself a severe problem. Instead of mangling the names in a way that preserves uniqueness like we did with So yes, we may as well percent encode every last But as far as the filenames themselves, I still do not think we should strip colons or spaces from the path element, as they are not invalid unless defined as such by the particular server, and because browsers are supposed to be able to display them. However, we could: A) provide the ability to specify a filename for the category, and/or B) extend In addition, the guide filename algorithm either needs fixing or to be modifiable by A or B. I was hoping other seasoned contributors might have thoughts of their own: @johnfairh, @jpsim, @segiddins, @pcantrell. |
I think the current scheme exists to try and make as many file names as possible not require percent encoding? |
Yeah I think so too. We should slug the category pages like we do for guide pages: until recently the data model didn't let these pages have different filenames to their display names but this is possible now. For compatibility, we probably have to do this only when needed vs. always. I don't think slug collision is a problem in practice but for sure, would be possible to spot and do something about. |
Can the filenames already be specified from the interface? (As a configuration or command line option?) That would be a viable workaround if it is.
Right now anything written in a language that does not use the latin alphabet gets completely obliterated so almost everything collides with almost everything. The example already given is a live (albeit superseded) project:
That is equivalent to having |
Nope, filenames can't be set; by data model I meant the internal ruby/mustache data. |
So it looks like fixing the filenames would be more involved and require more design thought. But we do all agree that any and all |
Fixed in master via #1094. |
Using for instance:
generates the following HTML:
which will cause the browser to attempt to load
Florp://%20Constants.html
rather thanhttp://url/to/docs/Florp%3A%20Constants.html
. Reproduced the same with?
,#
,%00
, and the space above isn’t encoded as%20
, so it seems no characters are being escaped at all. Tested with the fullwidth theme.The text was updated successfully, but these errors were encountered: