-
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
Semicolons should be legal in URL #2381
Comments
It's not just a semicolon... Rebol stops also with any of the delimiter chars, like
But I'm quite not sure if I like this proposal, because semicolon and other mentioned chars should be url-encoded, when you want to load it and if you have input from other sources, you should validate it anyway. One can always use this:
On the other side, the change may not be breaking too much existing data/code. But it is still change in the lexer, which I try to avoid personally. |
Good point about the brackets...although with the plan that most working on R3-Alpha code had agreed on, only ] and ) would be able to terminate a token. There would be 4 exceptions: But we don't want to sacrifice I feel like the other compromises in Rebol, like saying But one thing we can do to punt on the question is to just make the sequence illegal for now. If you see |
It works, if it is run through ENHEX.
According to https://developer.mozilla.org/en-US/docs/Glossary/percent-encoding braces do not need to be encoded. Copied here from: metaeducation/ren-c#1046 |
@IngoHohmann your example seems to be working in my branch: |
@IngoHohmann btw... I would use something like this:
instead:
And when posting issues here, you could try to use Rebol code... |
Semicolons in URLs are apparently legal:
https://stackoverflow.com/questions/1178024/can-a-url-contain-a-semi-colon
However, Rebol doesn't consider them to be part of a URL! when LOAD-ing, because the semicolon acts as a to-end-of-line comment.
Proposal would be that since a URL is delimited at its end by whitespace, that until whitespace is seen all characters are considered part of the content. This would match how a string doesn't consider a semicolon to be a comment if it is inside its delimiters, e.g. {foo ; not a comment}
The text was updated successfully, but these errors were encountered: