You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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}
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:
>> u: to-url {http://httpbin.org/get?q=foo;[()]boo}
== http://httpbin.org/get?q=foo%3B%5B%28%29%5Dboo
>> u: append http://httpbin.org/get?q= {foo;[()]boo}
== http://httpbin.org/get?q=foo%3B%5B%28%29%5Dboo
>> form u
== "http://httpbin.org/get?q=foo;[()]boo"
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.
Hostilefork commented on Jun 14, 2019:
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: ][, )(, ](, and )[. The idea that it would provide more lexical expansion possibilities in the future, if you could someday define what xy"abc" meant as being different from xy "abc".
But we don't want to sacrifice [1 2 http://3] as meaning the expected thing.
I feel like the other compromises in Rebol, like saying {a {b} c} is a legal string, may justify something like [1 2 http://httpbin.org/get?q=foo;[()]boo] working as a 3-element block, with a complete URL.
But one thing we can do to punt on the question is to just make the sequence illegal for now. If you see http://foo[ or http://foo; then make that an error. We are planning errors on things like [3()4] anyway.
Submitted by: Hostilefork
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}
Imported from: metaeducation#2381
Comments:
It's not just a semicolon... Rebol stops also with any of the delimiter chars, like
[
and(
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:
][
,)(
,](
, and)[
. The idea that it would provide more lexical expansion possibilities in the future, if you could someday define whatxy"abc"
meant as being different fromxy "abc"
.metaeducation#2094
But we don't want to sacrifice
[1 2 http://3]
as meaning the expected thing.I feel like the other compromises in Rebol, like saying
{a {b} c}
is a legal string, may justify something like[1 2 http://httpbin.org/get?q=foo;[()]boo]
working as a 3-element block, with a complete URL.But one thing we can do to punt on the question is to just make the sequence illegal for now. If you see
http://foo[
orhttp://foo;
then make that an error. We are planning errors on things like[3()4]
anyway.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
See also #2207, #1644
In #2012 also #1327, #1333 and #1644 are mentioned.
@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...
to text!
is Ren-C's feature.The text was updated successfully, but these errors were encountered: