AltME: Web


Does anyone know if there is any problem with using a ":" within a http URL, for the *target* part of the path.  
as such, the URL doesn't have any relation to physical disk paths.
I have the above working on a server, and browsers I've tested do not seem to have any problem with the URL, but I'm wondering more at large, if there are issues with it, in general.
It will be used  from within applications (java, .net, php & rebol) much more than from users manually using it within a browser bar.
rebol doesn't url encode the character, so it seems like its a valid character, but I don't want to assume, if some standard toolset doesn't like the color in the target.
color == colon  :-)
rfc1738 says ":" is a reserved character for possible special meaning in some schemes. It does not seem to have any special  meaning in the schemes mentioned in that URL.
But its reserved status means that it does not have to be encoded in any URL.
That's the theory, anyway. Practice may show otherwise.
The iMatix guys use it for both zeromq stuff and wikidot.
true, good references, so I won't panick about it then  :-)

to-url is your friend
Are you sure Max?
>> x: to-url "@@@"
== @@@
all the string-based datatype convertion funcs are flawed in some un-expected ways.   for example, you can to-word a lot of strings which aren't valid words.  
this is why I asked.  Although R2 doesn't complain, it doesn't mean tis valid or expected.
R3 did some housecleaning in type convertion consistency, but it has some flaws left (and I expect we will keep finding new ones).


Hi, I am looking into OAuth. I see (and thank you a lot for this!) that Chriss Ross Gill created OAuth client part in the twitter library: , I am reading into it, but does he or anyone else know how much additional work would be needed to do the rebol OAuth server part ?

I don't think it'd be that difficult - most of the difficulty in the client was making sure all the hashing was correct, the rest is just storage and logic.
For the most part, authorisation is based the parameters of a request hashed with a private key.  The trickiest part I'd imagine is the initial authentication - providing a safe method for the end user to allow the client to obtain and use the key.
End user downloads X's app/uses your
End user X downloads Y's app/uses Y's web site; X tries to access a function that uses your site; Y requests a temp key from you; Y directs X to your site with temp key, X says Y is OK, you give X a PIN; X goes back to Y, enters PIN; Y requests the permanent key from you.  Y can now do anything on your site on behalf of X.
Nothing to it : )

any tip for some session related function-set for REBOL CGI purposes? I am looking for the case, where Cheyenne is not an option, and need some simple stuff for sessions ....
acgiss.r from an option?

Last message posted 125 weeks ago.