World: r3wp

Pekr, the reasoning behind blocking patches is the same reason there 
is no browser plugin - R2 is insecure, and R3 won't be. Every patch 
that you can make in your %user.r is what malware running on your 
system can make with your user permissions.


The goal is to have tons of REBOL hosts around. Every application 
with a plugin interface could have a R3 host as a plugin. R3 is going 
to be able to generate programs now, not just scripts. It'll be a 
real development tool.


The problem with all this is that being able to patch the runtime 
using %rebol.r or %user.r, so can anyone else, and you won't know 
about it. Can you say exploit? We already had a false positive for 
R3 this year, an old alpha mistakenly marked as malware. We don't 
want the next time to be for real. The only way to avoid that is 
to make R3 secure.


The way to make something secure is to make the behavior of your 
code predictable. That means making your requirements explicit.

Anton, we are trying to come up with sensible defaults for all of 
the options. Get in on the conversation in R3 chat :)

It will be easy to specify your requirements in R3 - we have modules. 
Put your patches in a module and either add that module to the Needs 
header of your script, or include it on the command line, or build 
it into your host program. Like the SDK but better.

Petr: there is absolutely no reason to have your #1 as long as REBOL 
url!s are fixed.

Gabriele - I know - but do you remember how RT refused to allow dot 
in the front of email adress, because it went against RFC? :-) Hopefully 
we can fix it.

Gabriele - what is the problem with chunked mode of http 1.1 protocol, 
so that it is currently disabled? Any advice for a set-up, of how 
to debug it best? What is the chunked mode good for? I am willing 
to do some tests to track possible problems, so any quick pointer 
would be fine ...

Pekr, do you have problems with url! now? Doesn't it work as it should?

Yes, you can't parse ftp://[user-:-email-:-com]:[pass-:-ftp-:-domain-:-com]

the problem is @ char at the user part ... for R2, I used following 
code in user.r:


net-utils/url-parser/user-char: union net-utils/url-parser/user-char 
make bitset! #"@"

Ah yes, I remember something about that. I had same problem years 
ago. The url is correctly recognized as a url, but trying to use 
it, and it fails.

Pekr.. it's not too practical and safe to use urls with passwords. 
And if you need to connect to ftp with such a user's name, using 
scheme directly should work

Oldes - you see? that is exactly that nonsense excuse I am not willing 
to accept. This whole discussion was started only in regards to planned 
cancellation of user.r and rebol.r, so I was curious where I put 
my own patches ...

so - for me - it is bug in the parser, as such format is clearly 
allowed and is used daily on many sites, for others, it might not 
follow some RFC, and we have some workaround (RFC). But with REBOL, 
which does not use pure aproach here or there anyway, I don't see 
the reason why such stuff should not be possible. And xy users asking 
the same question over and over again thru all that years on ML prove 
me being right ...

workaround (RFC) = workaround (Scheme)

It should be fairly easy to make the change in REBOL, that you now 
do with a patch in user.r. I'm wondering, why it hasn't been corrected? 
Does it have other consequences?

no, I think no other consequences. IIRC, I extended that parser by 
# char too, but don't remember when it was. Remember - user.r and 
rebol.r are not going to be provided anymore, because of security 
reasons, so you have to either:

1) add your script into 'needs header for each of your script

2) start your script with special command line option, probably --include 
(but that does not allow simple double click functionality with associated 
executable)
3) build your own R3 host executable

4) prey, that your patch is usefull for others, and try to submit 
it to R3 CVS to be accepted

... still I hope that at least dialected preferences/init/config 
files will be possible ...

Geomol.. because there are people which wants to follow RFC! The 
above Pekr's "patch" is against RFC. One thing is, that you can use 
chars like @ in user name FTP's scheme. and another is that you cannot 
use it in URL. But that's not the topic here. The topic is,that Pekr 
want to modify his system against standarts - then he can use SDK 
and build his own URL handler.

Oldes - no, this is not topic either. The topic was patch system 
- no matter if any modification goes against standard or not.

I'm confused. Time to read some documentation...

I can live with above options R3 is going to provide, even if it 
will not be so simplistic as a R2 aproach. OTOH if it gives us stronger 
security, I can live with it even more ... I want browser plugin, 
hence security has to be solid ...

From RFC 1738:
Within the user and password field, any 
:",
   "@", or "/" must be encoded."


Pekr, can you get it to work without your patch, if you specify the 
at sign in the username as %40, like
ftp://john%40niclasen.name:[password-:-someserver-:-net]

Petr, chunked transfer mode is useful when an HTTP response is returned 
and the content length is unknown (for example, it is being dynamically 
generated from a source which is streaming it out). It can also exist 
when an HTTP response is being handled by intermediate proxies that 
could, for example, compress the response for a part of the path 
to the client. I've seen this on a cell phone where a POST was made 
with a fixed content length, but the web server received the request 
as chunked, with no length.

Petr: there is a misunderstanding here. REBOL URLs are AGAINST the 
RFC. That's a bug.

Re: chunked, I don't know, it was working fine last time I tested 
it. Something probably has changed in R3 in the meantime.

Note, re URL, the bug is not in the parser, the bug is in the URL! 
datatype.

note that ftp://[user-:-email-:-com]:[pass-:-ftp-:-domain-:-com] is WRONG. the 
correct URL is ftp://user%40email.com:[pass-:-ftp-:-domain-:-com] - but REBOL 
does not load it correctly.

It would be nice, if the parser auto encoded :, @ and / when needed.

are there any changes planned in R3 in the way objects work? like 
if you could have some "static" methods or properties that would 
not get copied but referenced when one object is derived from another?

I get second thought about auto encoding. The reason is, if url! 
have auto encoding of some characters, then it would be expected, 
that e.g. file! auto encode too. How do you specify a file named 
% on disk? In R3, you write: %%25

If the % char should be auto encoded, then you should write that 
filename as: %%
But what if your file is named %25 on disk?
It's a bit confusing, but what is the best way? Encoding or not?

Acutally file! does have auto encoding of space. You can specify 
a filename like this:
%"a b"
which will give %a b
So maybe auto encoding is a good thing in general?

url! already auto encode % in R3:

>> a%:b
== a%25:b

But I don't think, it's a valid url according to the standard:
http://en.wikipedia.org/wiki/URI_scheme#Generic_syntax

Actually the auto encoding was cousing me some problems some time 
ago. I'm not sure if it was fixed. Also with the auto encoding urls 
there is a problem, that for example the second @ char in Pekr's 
url must not be encoded.

Yeah. This seems funny! (Output from R3 console.)

>> %"@"
== %@
>> %@
== %25@

Can you guess the datatypes?

The first ends with a quotation mark also.

Geomol: PLEASE NO!!!! The bug that REBOL has is exactly THAT. I beg 
you guys, please NO! Encoding is there for a reason. If it could 
be done automatically, there would be no need for encoding!

Gabriele, so you mean, auto encoding shold be avoided? Should auto 
encoding be removed from these examples:

>> %"a b"
== %a b
>> a%[b-:-c]
== [a%25b-:-c]
>> a<>[b-:-c]
== [a%3C%3Eb-:-c]


My view is, that there is a lot of auto encoding already. If auto 
encoding should be there, it should be done right in all cases. Else 
it should be avoided alltogether. This situation with - some auto 
encoding in some cases but not all - is not good.

I guess, auto encoding is user-friendly, if it can be done right 
in all cases. With auto encoding, you don't have to remember all 
the strange encoding rules for different datatypes (especially url 
and email).


No auto encoding is technical-programmer-friendly. It's for the programmer, 
who knows all the strange rules and want complete control.


It goes beyond url and email. How should a space be represented in 
an issue! datatype? Like:

>> to-issue "a b"
== == #a?b

Today you just see a question sign, but it's a space in there.

That's a bug in issue! formatting.in R3: http://curecode.org/rebol3/ticket.rsp?id=700

Though strangely enough that is still better than the R2 behavior.

Geomol, yes. I would like to avoid auto encoding. It's exactly the 
case where I had the problems. If I write file as %"a b" and it's 
valid file, I prefere to have it samewhen I for example print it

Instead of auto encoding I would like to see such a basic functions 
like official url-encode presented in Rebol. (Of course we have our 
own - another %user.r usage)

I understand the concern against auto encoding. But without it, and 
with all the datatypes, we have in REBOL, good documentation about 
what encoding, we have to use for every datatype, is required.

I don't mind the ? issue! display in this case, but I'd like MOLD/all 
issue! to return a serialized encoding like: #[issue! "a b"]

In general I prefer simple encoding syntax rules over autoencoding, 
because it is easier to remember explicit rules than it is to remember 
magic dwim patterns.

Gabriele, RFC compliance of url encoding is important and will be 
fixed in upcoming R3 releases, even if I have to fix it myself. R2 
as well if I end up being the R2 release manager (it's possible).

Back after many weeks... how does one get on the r3-alpha world?

R3 chat. No more R3-Alpha world.

No more real work being done on R3 in AltME worlds.